tag:blogger.com,1999:blog-60232491854506527262024-03-18T18:36:31.406+01:00On Lean and AgilityAgile, Scrum, Kanban, Change Management. Und der Rest.Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comBlogger955125tag:blogger.com,1999:blog-6023249185450652726.post-27505776047075441192024-03-18T09:30:00.004+01:002024-03-18T09:30:00.139+01:00Ein Bild sagt mehr als 1000 Worte (XXXXI)<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhpMDiKnj_pgXvV73gJ_sjP0CuceRi32CCRZ916J_xdiYURFmCcWjVT0AccBs2Daq7n6Z29NdMfcH6jylrySKcatwuJqPsO8npqX2uEGq9p57lRoGppX40cqBrjzUgNiPVQVaBsVjdZa-NgAspTpUBmQ-WQ57Z0QJ4v11MpTXD3IgOP9n5SR2XYMZ_bAEm3/s1000/Rollercoaster.jpg" style="display: block; margin-left: auto; margin-right: auto; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="1000" data-original-width="639" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhpMDiKnj_pgXvV73gJ_sjP0CuceRi32CCRZ916J_xdiYURFmCcWjVT0AccBs2Daq7n6Z29NdMfcH6jylrySKcatwuJqPsO8npqX2uEGq9p57lRoGppX40cqBrjzUgNiPVQVaBsVjdZa-NgAspTpUBmQ-WQ57Z0QJ4v11MpTXD3IgOP9n5SR2XYMZ_bAEm3/w408-h640/Rollercoaster.jpg" width="408" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Grafik: <a href="https://www.designthinking.lol/comics/design-and-development-methodologies" target="_blank">Design Thinking! Comics</a><br /></td></tr></tbody></table>
<p>Den Vergleich von Produktentwicklungs-Vorhaben mit einer Acherbahnfaher kenne ich schon länger, aber noch nicht in dieser schönen Visualisierung.<br /></p>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-71231759446628742042024-03-14T09:30:00.006+01:002024-03-14T09:30:00.132+01:00Confidence Meter<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2eBC5jcTO6MLZQBNQtCERppqGEy_QcRkC7Kza-h7nBmdZynDdN40iowjP04BEqHWtfPjXt7KM6yCuaUbV3VxJYmKnN6hAQ2rrsrjHqR4aYkHl9CnaF4g1iy8o5vFDHaQFbvfSy25saRj92l7XC3SipuDGUyzxeV-CJKL_tjyXFxGXmW1fvK1oXesUra0K/s1200/Confidence-Meter-No-CC-scaled.jpg" style="display: block; margin-left: auto; margin-right: auto; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="794" data-original-width="1200" height="424" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2eBC5jcTO6MLZQBNQtCERppqGEy_QcRkC7Kza-h7nBmdZynDdN40iowjP04BEqHWtfPjXt7KM6yCuaUbV3VxJYmKnN6hAQ2rrsrjHqR4aYkHl9CnaF4g1iy8o5vFDHaQFbvfSy25saRj92l7XC3SipuDGUyzxeV-CJKL_tjyXFxGXmW1fvK1oXesUra0K/w640-h424/Confidence-Meter-No-CC-scaled.jpg" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Grafik: <a href="https://itamargilad.com/resources/confidence-meter-calculator/" target="_blank">Itimar Gilad</a> - <a href="https://creativecommons.org/licenses/by-sa/4.0/deed.en" target="_blank">CC BY-SA 4.0</a><br /></td></tr></tbody></table>
<p>Würde man die Entwicklungsteams dieser Welt diejenigen Fragen nennen lassen, die am schwersten zu beantworten sind, würde eine mit ziemlicher Sicherheit weit oben landen: "Wie sicher seid Ihr, dass Euer Produkt am Markt erfolgreich sein wird?" Vor allem wenn etwas neu entwickelt wird (<a href="https://www.lean-agility.de/2018/08/zeitschaetzungen-erfahrungen-und-prototypen.html" target="_blank">also in der IT eigentlich immer</a>) ist eine wirklich sichere Antwort aufgrund fehlender Erfahrungswerte kaum möglich, gleichzeitig ist die Antwort "Kann man nicht sagen" natürlich auch unbefriedigend, schliesslich müssen Investitions- oder Abbruch-Entscheidungen ja irgendwann getroffen werden. Ein Dilemma.<br /></p>
<p><br /></p>
<p>Ein Weg um aus diesem Dilemma zu entkommen und zu realistischen Zuversichts-Werten zu kommen ist das <a href="https://itamargilad.com/resources/confidence-meter-calculator/" target="_blank">Confidence Meter</a> von Itimar Gilad. Mit seiner Hilfe lässt es sich die Bewertung aus verschiedenen Einfluss-Faktoren ableiten, und das nicht etwa nur auf Basis von Bauchgefühl, sondern auf der Grundlage überprüfbarer und in ihrer Gewichtung abgestufter Erkenntnisse, bzw. Ergebnisse. Dadurch ist dieser daraus summierte Wert nicht nur differenzierter, er ist auch weniger anfällig für unrealistisch optimistische Selbsttäuschungen und Manipulationen. Die (vereinfachten) Faktoren sind: <br /></p>
<p><br /></p>
<h4 style="text-align: left;">Individuelle Überzeugungen (Zuversichtswert 0,1)<br /></h4>
<p>Damit fängt alles an. Irgendjemand (Person oder Gruppe) hat die initiale Idee und glaubt daran, dass aus ihr etwas Grosses werden kann. Das ist wichtig und darf nicht geringgeschätzt werden, eine auch nur irgendwie geartete Erfolgswahrscheinlichkeit lässt sich aber kaum daraus ableiten.<br /></p>
<p><br /></p>
<h4 style="text-align: left;">Ein Pitch Deck (Zuversichtswert 0,1)</h4>
<p>Sich selbst überzeugt zu haben ist ein erster Schritt, als nächstes gilt es andere zu überzeugen. Überlicherweise geschieht das mit einer Präsentation der (angenommenen) Potentiale und Vorteile. Die zu erstellen verhilft zu strukturierteren Annahmen, zu mehr aber noch nicht.<br /></p>
<p><br /></p>
<h4 style="text-align: left;">Aktuelle Trends, Moden und Buzzwords (Zuversichtswert 0,1)</h4>
<p>Man kann hier einen beliebigen Hype einsetzen: Digital, Mobil, KI, was auch immer. Darauf aufzuspringen erscheint naheliegend und verlockend, eine auch nur irgendwie geartete Erfolgswahrscheinlichkeit lässt sich aber noch immer kaum daraus ableiten.</p>
<p><br /></p>
<h4 style="text-align: left;">Unterstützende Meinungen (Zuversichtswert 0,5)</h4>
<p>Ab hier wird es schon ein ganz kleines bisschen objektiver. Wenn auch andere Personen der Meinung sind, dass die Idee Potential haben könnte, ist das eine erste Bestätigung. Und wenn diese Personen auch noch über Budgets oder sonstige Ressourcen verfügen, um so besser.<br /></p>
<p><br /></p>
<h4 style="text-align: left;">Schätzungen und Planungen (Zuversichtswert 0,5)</h4>
<p>Nehmen wir an, dass Budget da ist, jetzt kann überlegt werden, wie und wann es investiert wird. Das kann sehr dabei helfen, die Umsetzbarkeit zu beurteilen (ein durchaus wichtiger Punkt), ob das Produkt am Markt erfolgreich sein wird, ist aber noch immer sehr ungewiss.<br /></p>
<p><br /></p>
<h4 style="text-align: left;">Anekdotische Evidenz (Zuversichtswert 1)</h4>
<p>An dieser Stelle gibt es zum ersten Mal eine kleine empirische Validierung. Irgendwo ist ein (angeblich) vergleichbares Vorhaben erfolgreich gewesen. Darin steckt im Zweifel noch viel Hören-Sagen, aber zumindest ist es zum ersten Mal etwas, das über Vermutungen und Hoffnungen hinausgeht.<br /></p>
<p><br /></p>
<h4 style="text-align: left;">Marktforschung (Zuversichtswert 3)</h4>
<p>Mit Marktforschung wird Hören-Sagen durch eine erste, noch abstrakte, Bedarfsermittlung ersetzt. Ob die potentiellen Kunden und Nutzer aus diesem möglichen Bedarf eine konkrete Kaufentscheidung ableiten werden ist unklar, zumindest hat man sie jetzt aber erstmals überhaupt befragt.<br /></p>
<p><br /></p>
<h4 style="text-align: left;">Kunden-, bzw. Anwender-Wünsche (Zuversichtswert 3)</h4>
<p>Ab hier wird es konkreter. Konfrontiert mit den ersten Entwürfen des zukünftigen Produkts können potentielle Kunden und Nutzer Wünsche, Erwartungen und Nutzungs-Absichten äussern. Noch keine Erfolgsgarantie, aber ein starker Indikator.<br /></p>
<p><br /></p>
<h4 style="text-align: left;">Ergebnisse von Kunden-, bzw. Anwender-Tests (Zuversichtswert 5)<br /></h4>
<p>Aus dem starken wird an dieser Stelle ein sehr starker Indikator. Test- und Focus-Gruppen bekommen Prototypen oder MVPs zur Verfügung gestellt und können Rückmeldung zur Benutzungs-Erfahrung und zum wahrgenommenen Mehrwert geben, ggf sogar schon zur Kauf-Absicht.<br /></p>
<p><br /></p>
<h4 style="text-align: left;">Echte Verkaufs- und Nutzungsdaten (Zuversichtswert 10)</h4>
<p>In diesem letzten Stadium hat der Verkauf bereits begonnen und die ersten Zahlen zu Absatz und Nutzung wurden bereits ermittelt. Die Indikatoren werden jetzt nach und nach durch Beweise abgelöst, die Erfolgswahrscheinlichkeit ist klar abzusehen oder sogar bereits ermittelt.<br /></p>
<p><br /></p>
<p>Wie oben gesagt, diese Übersicht ist etwas vereinfacht, hinter den einzelnen Faktoren stecken nochmal Bandbreiten und Gewichtungen. Die Details dazu (inclusive einer Tabelle mit Berechnungsformeln) hat Itimar Gilad freundlicherweise <a href="https://itamargilad.com/resources/confidence-meter-calculator/" target="_blank">auf seiner Website</a> zur Verfügung gestellt. Wichtig ist aber, dass sich am Ende aus den Ausgangswerten der einzelnen Faktoren eine Gesamtsumme bildet, die einen realistischen, kaum verfälschbaren Zuversichtswert auf einer Skala zwischen 1 und 10 abbildet. <br /></p>
<p><br /></p>
<p>Was bei näherer Betrachtung dieses Modells auffällt ist, dass sich hohe Zuversichtswerte erst relativ spät, bzw. kurz vor dem Markteintritt ergeben können. Das ist für alle, die möglichst früh möglichst viel Sicherheit haben wollen, natürlich ärgerlich. Auf der anderen Seite ist es aber auch die harte Wahrheit - frühe Sicherheit gibt es bei neuen Produkten nicht. Wer nicht bereit ist das zu akzeptieren, dem werden auch Tools wie dieses hier nicht helfen.</p>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-56127255942014684202024-03-11T09:30:00.008+01:002024-03-11T20:31:06.949+01:00Kollabierende methodische Modelle<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEia716Ry4njmvCegN4DPnz15BAjJT-VP7EWe_NJVb8SHhwDrpW-isYwFdQf7OWUg7UAZ4jAInmMlkWo_G2aTVRE6bq0XMNZJEC9g773QafH-NYfh1xC55P0zTR6moT6-juHV94kXWIjTyuM9FE_YroyRKj4BjU8LulUOcqTWq09PY877EJxdVtHK0PrSBOL/s1024/Kollabierende%20methodische%20Modelle.jpg" style="display: block; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="640" data-original-width="1024" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEia716Ry4njmvCegN4DPnz15BAjJT-VP7EWe_NJVb8SHhwDrpW-isYwFdQf7OWUg7UAZ4jAInmMlkWo_G2aTVRE6bq0XMNZJEC9g773QafH-NYfh1xC55P0zTR6moT6-juHV94kXWIjTyuM9FE_YroyRKj4BjU8LulUOcqTWq09PY877EJxdVtHK0PrSBOL/w640-h400/Kollabierende%20methodische%20Modelle.jpg" width="640" /></a></div>
<p>Wenige Innovationen der letzten Jahrzehnte dürften so mit Hoffnungen und Erwartungen überladen sein wie die <a href="https://en.wikipedia.org/wiki/Generative_artificial_intelligence" target="_blank">generative künstliche Intelligenz</a> (in Form von Programmen wie Chat GTP, Gemini, o.Ä.). Um so ironischer dürfte es sein, dass wir durch sie etwas lernen können, was so niemand erwartet haben dürfte: wir können anhand der Evolution dieser Technologie erkennen, warum methodische Vorgehensweisen dem starken Risiko ausgesetzt sind, mit der Zeit unbrauchbar zu werden. Aber der Reihe nach.<br /></p>
<p><br /></p>
<p>Im Frühling 2023 veröffentlichten britische und kanadische Forscher die Studie <a href="https://arxiv.org/abs/2305.17493" target="_blank">The Curse of Recursion: Training on Generated Data Makes Models Forget</a>. In ihr belegten sie folgendes Phänomen: wenn eine künstliche Intelligenz (KI) nur zu Beginn auf Basis bestehender Datensätze trainiert wird, dann aber ihre auf dieser Basis generierten Ergebnisse wiederum zu dem Trainingsmaterial hinzugefügt werden, dann wird die Qualität der Ergebnisse mit zunehmender Zeit immer schlechter.<br /></p>
<p><br /></p>
<p>Der Grund dafür ist Folgender: die Generierung erfolgt (stark vereinfacht) durch die Ermittlung der Durchschnittswerte aus bestimmten thematisch zusammengehörigen Teilen des Trainingsmaterials. Dadurch gehen Nuancen und Kontext verloren, Trends und verbreitete Missverständnisse entwickeln dagegen ein überproportionales Gewicht. Fliessen die so erzeugten Ergebnisse wieder in das Traininingsmaterial ein, entsteht eine immer stärker werdende Verfälschungs-Dynamik.<br /></p>
<p><br /></p>
<p>Das Ergebnis dieser Dynamik ist der irgendwann stattfindende Modell-Kollaps (Modell steht hier stellvertretend für die KI-Programme): die generative KI hat mit der Zeit so viel fehlerhaftes Material erstellt, dass das Trainingsmaterial in einem derartigen Ausmass davon kontaminiert ist, dass die ursprünglichen, unkontaminierten Bestandteile in Relation dazu in den Hintergrund treten. Und auf Grundlage dieser fehlerhaften Basis entstehen ab jetzt im Wesentlichen falsche Ergebnisse.<br /></p>
<p><br /></p>
<p>Jetzt zur Übertragung auf methodische Vorgehensweisen. Auch diese beruhen zu Beginn (sofern sie seriös sind) auf empirisch erhobenen Erfahrungswerten und sind so in der Realität verankert. Auf dieser Basis entehen aber auch hier Ergebnisse (Konferenzbeiträge, Fachpublikationen, etc.), die populäre Irrtümer, Durchschnitte und Moden verstärkt abbilden. Und wenn das wieder in die Weiterentwicklung der Methodik einfliesst, droht der Kollaps dieser (mentalen) Modelle auch an dieser Stelle.<br /></p>
<p><br /></p>
<p>Die Folge dieser kollabierenden methodische Modelle sind deren zunehmende Entkoppelungen von der Realität, oft in Form von immer trivialer und <a href="https://www.lean-agility.de/2022/05/esoterik.html" target="_blank">esoterischer werdenden Frameworks und Methoden</a>. Transaktionale Führung, Selbstorganisation, Purpose oder ähnlich generische Konzepte werden undifferenziert und kontextbefreit zu Universallösungen erhoben, Management-Moden wie das "Spotify Model" oder OKRs werden mit unrealistischen Erfolgsversprechen verbunden, etc, etc.<br /></p>
<p><br /></p>
<p>Ein Weg, der aus dieser Situation herausführen kann, lässt sich übrigens erneut aus den Trainings der generativen KIs extrahieren. Diese führen nämlich dann wieder zu besseren Ergebnissen, wenn die selbsterzeugten Inhalte bewusst nicht in das Ausgangsmaterial weiterer Trainings aufgenommen werden (bzw. dort wo das bereits passiert ist wieder aus ihm entfernt werden), um so die sich selbst verstärkenden Verfälschungs-Kreisläufe gar nicht erst entstehen zu lassen. <br /></p>
<p><br /></p>
<p>Auf die Methodenwelt übertragen würde das bedeuten, Management-Moden, generische oder vereinfachte Ideen und stark kontextspezifische Fallstudien bewusst nicht in die Weiterentwicklung von Vorgehensmodellen einfliessen zu lassen und sich stattdessen auf empirische Validierung und wissenschaftliche Evidenz zu stützen. Inwiefern Organisationen wie das Project Management Institute oder Scaled Agile Inc. wohl dazu bereit wären, kann jeder für sich selbst zu bewerten versuchen.<br /></p>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-7869806568181459492024-03-07T09:30:00.006+01:002024-03-07T09:30:00.137+01:00Reed Hastings on the Netflix Culture<p>Dass Netflix eine agile Vorzeigefirma mit einer ganz besonderen Unternehmenskultur ist, weiss man spätestens seit <a href="https://www.lean-agility.de/2020/12/the-agile-bookshelf-no-rules-rules.html" target="_blank">No Rules Rules</a>, dem Buch seines CEO Reed Hastings. In diesem Interview in der Stanford Graduate School of Business erzählt er, wie sich sein Unternehmen und seine Kultur in den letzten Jahren weiterentwickelt haben und geht dabei auch auf einige Aspekte ein, die in seinem Buch noch nicht vorgekommen sind (z.B. den Einsatz künstlicher Intelligenz).<br /></p>
<p><br /></p>
<iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/u17n3UaH82k?si=o3T9yDYPT1rZLN75" title="YouTube video player" width="560"></iframe>
<p><br /></p>
<p>Für alle denen das noch nicht reicht, gibt es noch einen weiteren Einblick in die Netflix-Kultur, der aus einem etwas anderen Blickwinkel stattfindet. Kathryn Koehler hat in dieser Firma den bemerkenswerten Titel eines "Director of Productivity Engineering" und kann einiges zu ihrer Leistungskultur und deren Wandel in den letzten Jahren sagen. <a href="https://www.youtube.com/watch?v=_ed80YBOtZk" target="_blank">Zum Interview mit ihr geht es hier</a>.<br /></p>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-67558671184002796552024-03-04T09:30:00.001+01:002024-03-04T09:30:00.132+01:00Conway's Coaching<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEilHw-eGXhmgEgmSm0graqPxmnoNUw-H8aYMfefLk2bQiA8MAkSILpTky31-Ack6jePWUSCmt0Pn7wEjUi7F9IkUfbXQbWpOphs6M2AEjKZh5KLzQ7d6b1uo9cvnJGF16B_IHVUVaGIXCC0ss933vsBL3x2s6zyXyANrZ-OtyUVN8JcNHhbvhyLwAA6gSNi/s1000/Coaches.jpg" style="display: block; margin-left: auto; margin-right: auto; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="666" data-original-width="1000" height="426" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEilHw-eGXhmgEgmSm0graqPxmnoNUw-H8aYMfefLk2bQiA8MAkSILpTky31-Ack6jePWUSCmt0Pn7wEjUi7F9IkUfbXQbWpOphs6M2AEjKZh5KLzQ7d6b1uo9cvnJGF16B_IHVUVaGIXCC0ss933vsBL3x2s6zyXyANrZ-OtyUVN8JcNHhbvhyLwAA6gSNi/w640-h426/Coaches.jpg" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Bild: <a href="https://freerangestock.com/photos/121564/a-group-of-colleagues-raising-shaped-speech-bubble-cutouts.html" target="_blank">Freerangestock / Rawpixel</a> - <a href="https://freerangestock.com/licensing.php" target="_blank">License</a><br /></td></tr></tbody></table>
<p>Wenn sich Unternehmen einmal darauf eingelassen haben, ihren Mitarbeitern Coaches zur Seite zu stellen, kommt es immer wieder in der Folgezeit zu Ausdifferenzierungen dieser Rolle. In der Regel durch ein Präfix gekennzeichnet, entwickeln sich "Spezialisten-Coaches" für bestimmte Themengebiete, vom Quality Coach über den DevOps Coach bis zum Leadership Coach kann alles Mögliche dabei sein. Das ist auch erstmal ok, wie so oft kann man bei näherer Betrachtung aber Erstaunliches erkennen.<br /></p>
<p><br /></p>
<p>Viele der verschiedenen ausdifferenzierten Coach-Rollen werden weniger aufgrund von Nachfrage, Unternehmensstrategie oder sonstigen übergreifenden Notwendigkeiten und Zielen definiert, sondern aufgrund eines ganz anderen Kriteriums: der Organisationsstruktur. Sie werden innerhalb der vorhandenen Bereiche oder Abteilungen aufgebaut, deren Themengebiet dadurch auch zu ihrem Coaching-Gebiet wird. Zum Beispiel ist der Quality Coach in der Regel Teil einer Quality Assurance-Einheit.<br /></p>
<p><br /></p>
<p>Das ist zunächst einmal weder gut noch schlecht, und auch nicht ungewöhnlich. Die Tendenz, dass Organisationen ihre Organisationsstruktur auf alles mögliche übertragen ist so verbreitet, dass dieses Phänomen sogar als "Gesetzmässigkeit" formuliert wurde, <a href="https://www.lean-agility.de/2022/11/conways-law.html" target="_blank">Conways Law</a>. Ihm zufolge ist diese Übertragung sogar zwangläufig und findet praktisch jedes mal statt, wenn neue Systeme (vor allem technischer, aber auch sozialer Art) erschaffen werden.<br /></p>
<p><br /></p>
<p>Was diese "Gesetzmässigkeit" problematisch macht, ist, dass eine anhand der Organisationsstruktur vorgemommene Aufteilung nicht immer den gegebenen Notwendigkeiten entspricht, und ihnen mitunter sogar zuwiederläuft. Statt zusammengehörende Aspekte gemeinsam zu betrachten und basierend darauf zu entscheiden, welcher von ihnen den grössten Handlungsbedarf (bzw. in diesem Fall Coaching-Bedarf) hat, verengt sich der (Coaching-)Fokus unverhältnismässig stark auf einen Teilbereich.<br /></p>
<p><br /></p>
<p>Wer solche Konstellationen erlebt hat, wird es vermutlich kennen: der Product Coach hilft den Product Ownern bei Roadmaps und Kunden-Interaktionen, lenkt die Aufmerksamkeit seiner Coachees aber selten auf technische Probleme. Der Agile Coach dringt auf regelmässige Auslieferung, selbst wenn der Release-Zyklus durch eine jährliche Leitmesse vorgegeben ist, der QA Coach fördert durch seine ausschliessliche Arbeit mit den Testern unbewusst deren Separierung von den Entwicklern, etc. etc.<br /></p>
<p><br /></p>
<p>Wird diese Entwicklung erkannt, ist es ein häufiger Reflex, alle Coaches in zentralen Einheiten, oft "Coach Pool" genannt, zusammenzuziehen, die z.B. in HR oder Change Management verortet sind. Das scheint zunächst sinnvoll, da Gesamtsicht und Gesamtzuständigkeit entstehen, kann aber auch wieder in Conway's Law enden, da die jetzt übergeordnete zentrale Einheit ebenfalls Partikularinteressen hat, die den übergreifenden Unternehmenszielen ggf. nicht entsprechen.<sup>1</sup></p>
<p><br />
</p><p>Ebenfalls zu beachten ist, dass es auch sinnvolle Erwägungen gibt, die dazu führen, dass Conway's Law auch bei der Definition spezialisierter Coaching-Rollen stattfindet. In Fach- oder Spezialisten-Abteilungen verortete Coaches können bei ihrer Ausbildung und Weiterentwicklung von der hier vorhandenen Expertise profitieren, die in einer zentralen, organisationsübergreifenden Einheit naturgemäss nur schwach ausgeprägt sein kann.<br /></p>
<p><br /></p>
<p>Aus meiner Erfahrung ist ein anderer Weg besser: die "Spezialisten-Coaches" verbleiben zwar zum Zweck des Expertise-Aufbaus in ihren ursprünglichen Einheiten, sie bilden aber organisationsübergreifend eine Querschnittsorganisation, in der Einsatzplanung, Austausch, Abstimmung und das Setzen von gemeinsamen Standards stattfinden können, mit dem Ziel, dass trotz Spezialisierung eine Einheits-übergreifende Sicht auf die Gesamtorganisation und ihre Bedürfnisse und Notwendigkeiten möglich ist. <br /></p>
<p><br /></p>
<p>Wichtig dabei: wir sprechen immer noch von ausdifferenzierten Rollen, wie Quality Coach, DevOps Coach, etc. Bei Team Coaches mit fester Teambindung kann eine stärkere lokale Verankerung Sinn machen, das wäre aber nochmal ein eigenes Thema.<br /></p>
<p><br /></p>
<span style="font-size: xx-small;"><sup>1</sup>Ein häufiges Phänomen ist z.B. der Versuch einer "Optimierung" der Einsatzplanung, wodurch Coaching-Quantität auf Kosten von Coachin-Qualität gewonnen wird.</span><br />Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-24396150808084598292024-02-29T09:30:00.001+01:002024-02-29T09:30:00.160+01:00Kommentierte Links (CXI)<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBoBRmlz1efocOAdGT0kTPFJ7p1-p312jqD4pgLuqazXz25jySPUEr7D8em2LCLMBYBjcMlSXPXK2vksePu7roJY4OUC_ZzEOCPS9mKQ1IC2McWQONVaiMJ0RmQ15KtrkbORpnoUi0r-fmBveWJkVdu47aooY4In8kyS6CiVlP7os3TGEz1pzykUGZnw/s1000/Links.jpg" style="display: block; margin-left: auto; margin-right: auto; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="666" data-original-width="1000" height="426" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBoBRmlz1efocOAdGT0kTPFJ7p1-p312jqD4pgLuqazXz25jySPUEr7D8em2LCLMBYBjcMlSXPXK2vksePu7roJY4OUC_ZzEOCPS9mKQ1IC2McWQONVaiMJ0RmQ15KtrkbORpnoUi0r-fmBveWJkVdu47aooY4In8kyS6CiVlP7os3TGEz1pzykUGZnw/w640-h426/Links.jpg" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Grafik: <a href="https://pixabay.com/de/illustrations/internet-social-media-netzwerk-blog-4463031/" target="_blank">Pixabay / Geralt</a> - <a href="https://pixabay.com/de/service/license/" target="_blank">Lizenz</a></td></tr></tbody></table>
Das Internet ist voll von Menschen, die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.<br />
<br />
<h3><a href="https://hbr.org/2024/02/why-collaboration-is-critical-in-uncertain-times" target="_blank"> Jenny Fernandez, Kathryn Landis, Julie Lee : Why Collaboration Is Critical in Uncertain Times</a><br /></h3>
Obwohl es in diesem Artikel mehrerer Autoren des Harvard Business Review um das Thema der Zusammenarbeit geht, ist der Betrachtungswinkel weniger ein soziologischer oder systemtheoretischer und mehr ein psychologischer. Basierend auf mehreren wissenschaftlichen Studien beschreiben sie das Phänomen, dass Führungskräfte und Mitarbeiter in Krisensituationen dazu neigen, stärker miteinander zu konkurrieren, weniger Informationen zu teilen und mehr einsame Entscheidungen zu treffen. Da diese (auf unbewussten Mechanismen beruhenden) Muster aber zu tendenziell schlechteren Ergebnissen führen, ist es sinnvoll ihnen durch bewusst herbeigeführte, die Zusammenarbeit stärkende Massnahmen zu begegnen. Auch diese Massnahmen stellt der Artikel vor.<br />
<br />
<h3><a href="https://singhpr.medium.com/the-non-issue-of-team-size-aka-the-incomplete-understanding-of-complete-graphs-31286e555bd6" target="_blank">Prateek Singh: The Non-Issue of Team Size aka The Incomplete Understanding of Complete Graphs</a></h3>
Die Grafik mit der bei gleichmässig steigender Teamgrösse exponentiell steigenden Zahl an Kommunikations-Verbindungen (<a href="https://www.lean-agility.de/2017/10/ein-bild-sagt-mehr-als-1000-worte-xx.html" target="_blank">siehe hier</a>) dürfte eine der am häufigsten gezeigten sein, wenn es darum geht zu begründen, warum agile Teams eher klein sein sollten. Prateek Singh stellt allerdings die Aussagekraft dieser Darstellung in Frage, da er die Idee eines (grossen) Teams in dem jeder mit jedem kommuniziert in der Realität für kaum vorfindbar hält. Für realistischer hält er die Herausbildung von <a href="https://www.lean-agility.de/2024/02/scaled-agile-hubs.html" target="_blank">Kommunikations-Knoten (Hubs)</a>, durch die der Kommunikationsaufwand sich deutlich reduzieren lässt. In einem solchen Setting stellt die Grafik nur noch die <i>möglichen</i> Kommunikations-Verbindungen her, nicht mehr die <i>nötigen</i>. Damit hat er natürlich recht, ein Team möglichst klein zu halten ist aber aus vielen Gründen trotzdem erstrebenswert, so lange es nicht auf Kosten der Crossfunktionalität geht.<br />
<br />
<h3><a href="https://oneknightinproduct.substack.com/p/5-different-types-of-debt-that-can" target="_blank">Jason Knight: 5 Different Types of Debt That Can Hinder Your Product Organisation</a><br /></h3>
Über Technische Schulden und Organisatorische Schulden habe ich bereits selbst etwas geschrieben (<a href="https://www.lean-agility.de/2022/04/technische-schulden.html" target="_blank">hier</a> und <a href="https://www.lean-agility.de/2016/04/organisatorische-schulden.html" target="_blank">hier</a>), Jason Night fügt diesem Konzept noch drei weitere Dimensionen hinzu: die Produkt-Schulden, die Visions-Schulden und die Einnahmequellen-Schulden. Allen ist gemeinsam, dass es sich um ursprünglich aus guten Gründen (bzw. aus der Not heraus) getroffene Entscheidungen handelt, die aber in einer langfristigen Betrachtung Inkonsistenz, Ineffizienz oder Ineffektivität zur Folge haben, die mit z.T. grossem Aufwand korrigiert werden müssen (dieser Aufwand ist das "Zurückzahlen" der Schulden, daher die Analogie). Grundsätzlich gilt: diese verschiedenen Arten von Schulden sind nicht per se schlecht, sie müssen aber bewusst aufgenommen und planmässig abgebaut werden.<br />
<br />
<h3><a href="https://agileotter.blogspot.com/2024/02/definition-by-dysfunction.html" target="_blank">Tim Ottinger: Definition-by-Dysfunction</a></h3>
Wer Twitter und Linkedin nach Meinungen zu den agilen Frameworks (oder zur Agilität im Allgemeinen) durchsucht, wird einen bestimmten Typ erstaunlich häufig finden: kategorische und z.T. hochemotionale Ablehnungen, die aber auf Aspekten beruhen, die in keinem einzigen Framework enthalten sind (Sprints mit unrealistisch hoher Arbeitsmenge, Unterlassen von Planung und Dokumentation, alberne Spiele in Retrospektiven, etc.). Tim Ottinger gibt diesem Phänomen einen Namen: Definition by Dysfunction (sinngemäss übersetzt: eine Vorstellung die auf einem dysfunktionalen Kennenlern-Kontext beruht). Dafür, dass die Erkenntnis, einer Definition by Dysfunction aufgesessen zu sein, erhellend sein kann, ist er selbst ein gutes Beispiel - ursprünglich ein Gegner von Scrum, findet er den Ansatz mittlerweile (seit er ihn in Original kennt) gut.<br />
<br />
<h3><a href="https://www.nytimes.com/interactive/2024/02/13/arts/television/taylor-tomlinson-have-it-all-netflix.html" target="_blank">Jason Zinoman: How Taylor Tomlinson Nailed Her Closing Joke</a></h3>
Auch ausserhalb der "agilen Blase" gibt es die Idee kontinuierlicher incrementeller Überprüfung und Verbesserung. Dieses Beispiel hier ist besonders anschaulich: Jason Zinomann, ein Journalist der New York Times, hat die Komikerin <a href="https://en.wikipedia.org/wiki/Taylor_Tomlinson" target="_blank">Taylor Tomlinson</a> in den neun Monaten vor einem großen, für das Fernsehen aufgezeichneten Auftritt begleitet und dabei dokumentiert, wie einzelne Elemente ihres finalen Auftritts immer wieder in kleineren Auftritten erprobt, basierend auf dem Feedback des Publikums optimiert und danach erneut erprobt wurden. Ohne den Begriff zu nennen (und vermutlich ohne sich dessen bewusst zu sein) ist das die Anwendung agiler Praktiken bei der Entwicklung eines Bühnenprogramms.<br />Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-5036289722662520032024-02-26T09:30:00.005+01:002024-02-26T09:30:00.130+01:00Warum gerade viele Scrum Master und Agile Coaches ihren Job verlieren<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: left;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHSrEdFwkzn4tIrXJrkXj9VoWOFUqRP0KAjzvH0HvERHdPHND_tJop444297jG6Mlv_gzjrL7cGP3cFT97td_do5M6C0iozuIgyt-4HaOjengTHV_txXYnnVx8p46auZ6dJf-t6gdMUA90CH-tqM3BDrqEekXUn-sZrCz_6_BnXBVklimn6zsjFfOdQFQ2/s1000/Fired.jpg" style="display: block; margin-left: auto; margin-right: auto; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="666" data-original-width="1000" height="426" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHSrEdFwkzn4tIrXJrkXj9VoWOFUqRP0KAjzvH0HvERHdPHND_tJop444297jG6Mlv_gzjrL7cGP3cFT97td_do5M6C0iozuIgyt-4HaOjengTHV_txXYnnVx8p46auZ6dJf-t6gdMUA90CH-tqM3BDrqEekXUn-sZrCz_6_BnXBVklimn6zsjFfOdQFQ2/w640-h426/Fired.jpg" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Bild: <a href="https://www.pexels.com/photo/a-man-in-gray-suit-8279211/" target="_blank">Pexels / Antoni Shkraba</a> - <a href="https://www.pexels.com/de-de/lizenz/" target="_blank">Lizenz</a></td></tr></tbody></table>
<p>In vielen Unternehmen ist gerade ein scheinbar paradoxes Nebeneinander von zwei Phänomenen zu beobachten. Zum einen ist mittlerweile allgemein anerkannt, dass Firmen agil (d.H. in kurzen Abständen Liefer- und Reaktionsfähig) sein müssen, um Umbrüchen wie Wirtschaftskrisen, Covid19 oder dem Aufstieg von KI-Anwendungen begegnen zu können. Zum anderen trennen sich gerade viele Firmen von ihren Scrum Mastern, Agile Coaches und sonstigen "agilen Methodikern". Wie passt das zusammen?<br /></p>
<p><br /></p>
<p>Spricht man mit Managern in diesen Unternehmen, ist die meistens von ihnen kommende Erklärung eine, die für besagte Methodiker nicht besonders angenehm ist: ja, Agilität ist wichtig und wird (wenn auch z.T. unter anderen Namen) weiter angestrebt. Dass trotzdem gleichzeitig Scrum Master- und Agile Coach-Stellen abgebaut werden liegt daran, dass aus Unternehmenssicht nicht erkennbar ist, dass diese in nennenswertem Ausmass zu diesem Ziel (agil zu werden oder zu bleiben) beitragen.<br /></p>
<p><br /></p>
<p>Diese Bewertung ist heftig und muss darum eingeordnet werden. Zum einen gibt es natürlich auch viele Firmen, in denen nicht so gedacht wird und in denen die agilen Methodiker weiterhin eine hohe Wertschätzung erfahren. Des Weiteren beruhen derartig negative Beurteilungen mitunter auf Unwissen oder hidden Agendas. Die schiere Menge der Fälle legt aber nahe, dass auch solche dabei sind, in denen diese negative Aussenwahrnehmung gerechtfertigt ist.<sup>1</sup><br /></p>
<p><br /></p>
<p>Wenn wir unterstellen, dass diese Rollen grundsätzlich Sinn machen (ein Argument dafür <a href="https://www.lean-agility.de/2019/07/raus-aus-dem-hamsterrad.html" target="_blank">findet sich hier</a>), stellt sich jetzt die Frage, was in so vielen Firmen falsch läuft. Was sind die Gründe dafür, dass Scrum Master und Agile Coaches dort nicht dazu beitragen, die Produktentwicklung agiler zu machen? Die Gründe dürften vielfältig sein, nachdem ich in zahlreichen Unternehmen bestimmte Muster immer wieder erlebt habe, wage ich aber die Hypothese, dass die folgenden Ursachen eine zentrale Rolle spielen:<br /></p>
<p><br /></p>
<h4>Fehlende Methoden-Expertise<br /></h4>
<p>Eine der irritierendsten Beobachtungen zu Beginn: viele Methodiker haben nur ein erstaunlich dünnes Methodenwissen. Häufig beschränkt es sich auf Scrum (und selbst das manchmal nur oberflächlich<sup>2</sup>), Kanban wird auf ein Task-Board mit WIP-Limits reduziert, von SAFe sind nur die inneren Mechaniken der Release Trains bekannt, etc. Das engt nicht nur den eigenen Werkzeugkasten ein, es führt auch zum Verlust des Status als Experte für Agilität und Organisationsentwicklung.<br /></p>
<p><br /></p>
<h4>Fehlende technische Expertise<br /></h4>
<p>Um einem häufigen Einwand direkt zu begegnen - nein, ein Scrum Master oder Agile Coach muss keinen Code schreiben können. Er sollte aber zumindest auf einer abstrakten Ebene verstanden haben, was Continuous Integration, Feature Toggles, Code Coverage und Software Architektur mit Agilität zu tun haben. Ist das nicht der Fall, wird er viele Impediments und Wissenslücken in seiner Umgebung nicht erkennen und damit auch nicht beheben können.<br /></p>
<p><br /></p>
<h4>Fehlende fachliche Expertise<br /></h4>
<p>Auch hier eine direkte Erwiderung auf einen häufigen Einwand - ja, das ist das Themengebiet des Product Owners. Aber: die Beratung des Product Owners gehört zu den expliziten Aufgaben des Scrum Masters. Und zumindest dort wo Elemente der Fachlichkeit mit dem agilen Vorgehen zu kollidieren drohen (z.B. im Fall von Vorgaben durch gesetzliche Regulierung) müssen diese bekannt und verstanden sein, um ein mit ihnen kompatibles und trotzdem agiles Vorgehensmodell entwickeln zu können. <br /></p>
<p><br /></p>
<h4>Fehlende wirtschaftliche Expertise<br /></h4>
<p>Dass viele Scrum Master und Agile Coaches dieses Themengebiet nicht als ihres ansehen ist ein schwerwiegendes Missverständnis. Time to Market, Minimum Viable Products, Lead Times, Technische Schulden, (die Vermeidung von) Waste und viele andere Themen sind zutiefst betriebswirtschaftlich und gleichzeitig von zentraler Bedeutung für agile Produktentwicklung. Wer sie nicht kennt wird sich oft schwer damit tun, einem Stakeholder die Sinnhaftigkeit agilen Arbeitens zu erklären.<br /></p>
<p><br /></p>
<h4>Fehlendes Systemverständnis<br /></h4>
<p>Gemeint ist hier das Gesamtsystem. Ausserhalb der eigentlichen Produktentwicklung gibt es verschiedene Prozesse und Einheiten, die starke Einflüsse auf den Grad der möglichen Agilität haben: von Budgeting und Compliance über HR und Betriebsrat bis hin zum Facility Management. Ähnlich wie im Fall der technischen Expertise ist es ohne Systemverständnis an vielen Stellen nicht möglich, Impediments zu erkennen (und damit auch nicht, sie zu lösen).<br /></p>
<p><br /></p>
<p>Um es noch ein weiteres mal zu wiederholen: es gibt viele Firmen in denen sich andere Konstellationen finden lassen, die gerade genannten Qualifikationslücken sind also keineswegs typisch für die agilen Methoden-Berufe. Es gibt aber eine signifikante Menge in dieser Gruppe, die diese Aspekte (bewusst oder unbewusst) wenig beachtet hat, um sich stattdessen mit Themen wie Coaching, Achtsamkeit und kreativer Meeting-Moderation zu beschäftigen. Nicht dass die keine Berechtigung hätten, aus einer unternehmerischen Sicht sind sie aber deutlich weniger wichtig als die zuvor genannten.<br /></p>
<p><br /></p>
<p>Was man für ein vollständiges Bild aber auch sagen muss: aus einer unternehmerischen Sicht ist es ebenfalls sinnvoll und notwendig, die oben genannten Themengebiete in die Ausbildung und Weiterentwicklung der eigenen Scrum Master und Agile Coaches zu integrieren. Dort wo das geschehen ist, dürften diese Jobs wertstiftend (und damit sicher) sein. Dort wo es nicht geschehen ist sollte man sich fragen, ob die aktuellen Entlassungen nicht auch ein Zeugnis einer verfehlten Personalpolitik sind.<br /></p><br /><p><br /></p>
<span style="font-size: xx-small;"><sup>1</sup>Alleine im Grossraum Köln/Bonn weiss ich von einer dreistelligen Zahl an Scrum Master-, Agile Coach- und Release Train Engineer-Stellen, die gestrichen oder zu Teilzeit-Tätigkeiten reduziert wurden<br />
<sup>2</sup>Klassische Missverständnisse sind das Weglassen zentraler Elemente, wie z.B. den Sprint Zielen, bei gleichzeitigem dogmatischem Beharren auf optionalen Elementen wie den Story Points oder der Definition of Ready</span>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-49751976970174767742024-02-22T09:30:00.001+01:002024-02-22T09:30:00.136+01:00Scaled Agile: Hubs<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkNceGxI_wIGROifhYpowz_MKIyMqKxcx9YDurL2g1scCeH43q4DUNQ_1ib06n13Ue8t7sZNW6r1Y7P4SHeQtuIDBFz-oFZfQILmZPG4e0r_L-GwgiUpy3I1wkiEE9Ukq5ZTuWkG66OsIeuA8RWVhUGA9pSmYtXvVog5SYdlU3cDu7S26BgfWlJo2d5bz3/s1024/Light%20Hubs.jpg" style="display: block; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="640" data-original-width="1024" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkNceGxI_wIGROifhYpowz_MKIyMqKxcx9YDurL2g1scCeH43q4DUNQ_1ib06n13Ue8t7sZNW6r1Y7P4SHeQtuIDBFz-oFZfQILmZPG4e0r_L-GwgiUpy3I1wkiEE9Ukq5ZTuWkG66OsIeuA8RWVhUGA9pSmYtXvVog5SYdlU3cDu7S26BgfWlJo2d5bz3/w640-h400/Light%20Hubs.jpg" width="640" /></a></div>
<p>Wir alle kennen den für agile Teams anzustrebenden Idealzustand: crossfunktional, d.h. in der Lage, alle notwendigen Tätigkeiten selbst auszuüben, und selbstorganisiert, d.h. in der Lage, selbst darüber entscheiden zu können, welche dieser Tätigkeiten wann durchgeführt wird. In der Realität gibt es aber immer wieder Sachzwänge wirtschaftlicher oder regulatorischer Art, die diesen Idealzustand einschränken. Das macht Kommunikation und Koordination mit anderen Teams nötig. <br /></p>
<p><br /></p>
<p>Je nachdem wie (un)hierarchisch eine Organisation aufgestellt ist, kann die Gestaltung dieser Kommunikationsströme unterschiedliche Formen annehmen. Der klassische Weg ist dabei der durch das Management. Ein Team-, Abteilungs- oder Projektleiter sammelt die zu besprechenden Themen in seiner Einheit ein, trifft sich mit seinem Gegenpart aus der anderen Einheit, der dort vorher das Gleiche gemacht hat, bespricht alles mit ihm und bringt die Ergebnisse zurück zu seinen Leuten.<br /></p>
<p><br /></p>
<p>Eine solche Lösung ist zwar naheliegend, allerdings aus verschiedenen Gründen problematisch. Entscheidungskompetenz und Umsetzungsexpertise werden entkoppelt, diese Art der Informationsübermittlung dauert relativ lange, durch die verschiedenen Kommunikations-Stationen entsteht das Risiko von Stille Post-Effekten und es kann sich (ggf. unbeabsichtigt) beim Management Herrschaftswissen herausbilden. <br /></p>
<p><br /></p>
<p>Der häufig propagierte "agile Gegenentwurf" ist die Netzwerk-Organisation. Hierarchien kann es zwar auch hier noch geben, die Kommunikationsströme richten sich aber nicht mehr an ihnen aus. Stattdessen kann jeder Einzelne mit jedem Anderen (sowohl Personen als auch Gruppen) Kontakt aufnehmen und anstehende Themen besprechen und Klären. Gegebenenfalls können dabei auch direkte Kommunikationen zwischen unterschiedlichen Hierarchie-Ebenen zustande kommen.<br /></p>
<p><br /></p>
<p>Auch diese Lösung ist aber nicht unproblematisch. Es besteht das Risiko, dass die Kommunikation zerfasert und unübersichtlich wird, mit der Folge, dass entweder Redundanzen entstehen (die im schlimmsten Fall zu verschiedenen, ggf. inkompatiblen Lösungen für das selbe Problem führen), oder dass ein unverhältnismässig hoher Aufwand investiert werden muss, um für jeden nachvollziebar zu machen, wer gerade mit wem über welches Thema spricht.<br /></p>
<p><br /></p>
<p>Ein Versuch, einen Mittelweg zwischen diesen beiden Extremen zu finden, kommt von James Coplien, einem der unbekannteren Pioniere der agilen Software-Entwicklung (unter anderem <a href="https://www.scruminc.com/origins-daily-scrum/" target="_blank">hat er das Daily Scrum/Daily Standup erfunden</a>). In seinem Ansatz der <a href="https://www.lean-agility.de/2022/05/scaling-with-scale-free-networks.html" target="_blank">Scale Free Organisation</a> ergänzt er die Netzwerk-Organisation um Personen, die Informationsknotenpunkte, die so genannten Hubs, bilden, welche die zu kommunizierenden Informationen konsolidieren, bzw. verteilen.<br /></p>
<p><br /></p>
<p>Der Unterschied zu dem Management-zentrierten Ansatz ist, dass es sich bei diesen die Informationen konsolidierenden, bzw. verteilenden Personen <u>nicht</u> um Manager oder sonstige Funktionsträger handelt, sondern lediglich um Menschen, die aufgrund ihrer Kommunikativität, ihrer Versetzungshistorie, ihrer Bereitschaft Wissen zu teilen oder sonstiger Faktoren (z.B. der Mitgliedschaft im Betriebssportverein) überdurchschnittlich viele andere Menschen kennen und bei Bedarf Kontakt zu ihnen herstellen können.<br /></p>
<p><br /></p>
<p>Ebenfalls im Unterschied zum Management-zentrierten Ansatz erfolgt die Herausbildung von Hubs selbstorganisiert, emergent und ggf. temporär. Mit anderen Worten: da kommunikative und/oder gut vernetzte Personen mit höherer Wahrscheinlichkeit angesprochen werden oder an Abstimmungs-Meetings (z.B. einem <a href="https://www.lean-agility.de/2016/08/scaled-agile-scrum-of-scrums-und-communities-of-practice.html" target="_blank">Scrum of Scrums</a>) teilnehmen werden als andere, verstärkt sich ihr Hub-Status selbst. Fallen Hubs aus (z.B. durch Versetzung) entsteht durch die gleichen Mechanismen ein Ersatz.<br /></p>
<p><br /></p>
<p>Bedingt durch diese Selbstorganisations- und Kompensationsmechanismen (die Coplien <a href="https://www.youtube.com/watch?v=Va8QedfiC9k&t=1547" target="_blank">in 200 von ihm untersuchten Unternehmen</a> identifizieren konnte) sind Organisationen, deren Kommunikation über derartige Hubs läuft, mit einer hohen Effektivität, Flexibilität und Resilienz ausgestattet, da in ihnen direkte Verbindungen immer da entstehen wo sie gerade gebraucht werden, ohne dass sie sich durch Regulierung oder Normierung verfestigen.<br /></p>
<p><br /></p>Ein interessanter Aspekt, auf den Coplien aber nicht eingeht, ist die Frage, ob sich in formal Management-zentrierten Organisationen <a href="https://en.wikipedia.org/wiki/Formal_organization#Distinction_from_informal_organization" target="_blank">informelle Strukturen</a> in Form von Hubs herausbilden können. <a href=" Wir alle kennen den für agile Teams anzustrebenden Idealzustand: crossfunktional, d.h. in der Lage, alle notwendigen Tätigkeiten selbst auszuüben, und selbstorganisiert, d.h. in der Lage, selbst darüber entscheiden zu können, welche dieser Tätigkeiten wann durchgeführt wird. In der Realität gibt es aber immer wieder Sachzwänge wirtschaftlicher oder regulatorischer Art, die diesen Idealzustand einschränken. Das macht Kommunikation und Koordination mit anderen Teams nötig. Je nachdem wie (un)hierarchisch eine Organisation aufgestellt ist, kann die Gestaltung dieser Kommunikationsströme unterschiedliche Formen annehmen. Der klassische Weg ist dabei der durch das Management. Ein Team-, Abteilungs- oder Projektleiter sammelt die zu besprechenden Themen in seiner Einheit ein, trifft sich mit seinem Gegenpart aus der anderen Einheit, der dort vorher das Gleiche gemacht hat, bespricht alles mit ihm und bringt die Ergebnisse zurück zu seinen Leuten. Eine solche Lösung ist zwar naheliegend, allerdings aus verschiedenen Gründen problematisch. Entscheidungskompetenz und Umsetzungsexpertise werden entkoppelt, diese Art der Informationsübermittlung dauert relativ lange, durch die verschiedenen Kommunikations-Stationen entsteht das Risiko von Stille Post-Effekten und es kann sich (ggf. unbeabsichtigt) beim Management Herrschaftswissen herausbilden. Der häufig propagierte "agile Gegenentwurf" ist die Netzwerk-Organisation. Hierarchien kann es zwar auch hier noch geben, die Kommunikationsströme richten sich aber nicht mehr an ihnen aus. Stattdessen kann jeder Einzelne mit jedem Anderen (sowohl Personen als auch Gruppen) Kontakt aufnehmen und anstehende Themen besprechen und Klären. Gegebenenfalls können dabei auch direkte Kommunikationen zwischen unterschiedlichen Hierarchie-Ebenen zustande kommen. Auch diese Lösung ist aber nicht unproblematisch. Es besteht das Risiko, dass die Kommunikation zerfasert und unübersichtlich wird, mit der Folge, dass entweder Redundanzen entstehen (die im schlimmsten Fall zu verschiedenen, ggf. inkompatiblen Lösungen für das selbe Problem führen), oder dass ein unverhältnismässig hoher Aufwand investiert werden muss, um für jeden nachvollziebar zu machen, wer gerade mit wem über welches Thema spricht. Ein Versuch, einen Mittelweg zwischen diesen beiden Extremen zu finden, kommt von James Coplien, einem der unbekannteren Pioniere der agilen Software-Entwicklung (unter anderem hat er das Daily Scrum/Daily Standup erfunden). In seinem Ansatz der Scale Free Organisation ergänzt er die Netzwerk-Organisation um Personen, die Informationsknotenpunkte, die so genannten Hubs, bilden, welche die zu kommunizierenden Informationen konsolidieren, bzw. verteilen. Der Unterschied zu dem Management-zentrierten Ansatz ist, dass es sich bei diesen die Informationen konsolidierenden, bzw. verteilenden Personen nicht um Manager oder sonstige Funktionsträger handelt, sondern lediglich um Menschen, die aufgrund ihrer Kommunikativität, ihrer Versetzungshistorie, ihrer Bereitschaft Wissen zu teilen oder sonstiger Faktoren (z.B. der Mitgliedschaft im Betriebssportverein) überdurchschnittlich viele andere Menschen kennen und bei Bedarf Kontakt zu ihnen herstellen können. Ebenfalls im Unterschied zum Management-zentrierten Ansatz erfolgt die Herausbildung von Hub-Personen selbstorganisiert, emergent und ggf. temporär. Mit anderen Worten: da kommunikative und/oder gut vernetzte Personen mit höherer Wahrscheinlichkeit angesprochen werden oder an Abstimmungs-Meetings (z.B. einem Scrum of Scrums) teilnehmen werden als andere, verstärkt sich ihr Hub-Status selbst. Fallen Hubs aus (z.B. durch Versetzung) entsteht durch die gleichen Mechanismen ein Ersatz. Bedingt durch diese Selbstorganisations- und Kompensationsmechanismen (die Coplien in 200 von ihm untersuchten Unternehmen identifizieren konnte) sind Organisationen deren Kommunikation über derartige Hubs läuft mit einer hohen Effektivität, Flexibilität und Resilienz ausgestattet, da in ihnen direkte Verbindungen immer da entstehen wo sie gerade gebraucht werden, ohne dass sie sich durch Regulierung oder Normierung verfestigen. Ein interessanter Aspekt, auf den Coplien aber nicht eingeht, ist die Frage, ob sich in formal Management-zentrierten Organisationen informelle Strukturen in Form von Hubs herausbilden können, Die Erfahrung spricht dafür, ob es wirklich in nennenswertem Ausmass der Fall ist wäre aber ein interessantes Forschungsfeld für die Organisationssoziologie." target="_blank">Die Erfahrung</a> spricht dafür, ob es wirklich in nennenswertem Ausmass der Fall ist, wäre aber ein interessantes Forschungsfeld für die Organisationssoziologie.<br />Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-18765843031404853962024-02-19T09:30:00.001+01:002024-02-19T09:30:00.132+01:00Ein Bild sagt mehr als 1000 Worte (XXXX) <p> </p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiT4Y090MZnCI9T1d3vVC3tuEM_UgkVm6V0Wl_blc2Uqezm8MoCes_aaxTKn1PvMq5tZadgUtE5JKRCcwxiADfJqftIfb7ElgXTHhU4x49dvHP797mtduwX0M0-ovNrtxAgFfrkTlUKRj5BMxQc56uYhyphenhyphenQiVRSR7S_4DWq7jFav0iBNQD-z7-QVVtkmXwek/s1200/All%20pull%20requests%20have%20been%20merged.jpg" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1200" data-original-width="1200" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiT4Y090MZnCI9T1d3vVC3tuEM_UgkVm6V0Wl_blc2Uqezm8MoCes_aaxTKn1PvMq5tZadgUtE5JKRCcwxiADfJqftIfb7ElgXTHhU4x49dvHP797mtduwX0M0-ovNrtxAgFfrkTlUKRj5BMxQc56uYhyphenhyphenQiVRSR7S_4DWq7jFav0iBNQD-z7-QVVtkmXwek/w640-h640/All%20pull%20requests%20have%20been%20merged.jpg" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Bild: <a href="https://turnoff.us/geek/the-depressed-developer-45/" target="_blank">{turnoff.us} / Daniel Stori</a> - <a href="https://creativecommons.org/licenses/by-nc-nd/4.0/" target="_blank">CC BY-NC-ND 4.0</a></td></tr></tbody></table><br /><p></p>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-54308687075501554362024-02-16T09:30:00.007+01:002024-02-16T09:30:00.124+01:00Agile Success Stories: die Wiederauferstehung des abgeschriebenen Teams<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsEpMeU29QvqJraE2skMuIYPcZR-0YK3Z6vt0W-lP2VRdXm9qWc29gav7Ws8MpkUui8ElsKFb6jTwgobeQq6BwURPz131mgpo6wxECYedutMqEuYpYWo7gYnr-5EFKOGdiGVg2Ec0M7l1Izshc3TqY_I5qOgykTdk38PblBEI2iH4RqoNlsX092xWiR39h/s1280/Agile%20Success%20Story.jpg" style="display: block; margin-left: auto; margin-right: auto; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="853" data-original-width="1280" height="426" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsEpMeU29QvqJraE2skMuIYPcZR-0YK3Z6vt0W-lP2VRdXm9qWc29gav7Ws8MpkUui8ElsKFb6jTwgobeQq6BwURPz131mgpo6wxECYedutMqEuYpYWo7gYnr-5EFKOGdiGVg2Ec0M7l1Izshc3TqY_I5qOgykTdk38PblBEI2iH4RqoNlsX092xWiR39h/w640-h426/Agile%20Success%20Story.jpg" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Bild: <a href="https://www.pexels.com/photo/people-celebrating-at-the-office-7793999/" target="_blank">Pexels / Yan Krukau</a> - <a href="https://www.pexels.com/de-de/lizenz/" target="_blank">Lizenz</a> </td></tr></tbody></table>
<p>Leider ist es so, dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln. Das ist auch menschlich verständlich, wer sich ständig mit dem Beseitigen von <a href="https://www.lean-agility.de/2022/10/impediments.html" target="_blank">Impediments</a> und dem Kampf gegen <a href="https://www.lean-agility.de/2016/11/change-fatigue.html" target="_blank">Change Fatigue</a> und <a href="https://www.lean-agility.de/2016/08/konzern-trolle.html" target="_blank">Konzern-Trolle</a> beschäftigen muss, kann leicht in Frustration abrutschen. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.<br /></p>
<p><br /></p>
<p>Diese hier begann zuerst wenig verheissungsvoll. Eine der ersten Aussagen am ersten Tag in einem Team, das ich als Agile Coach begleiten sollte, kam vom Product Owner und lautete, dass solange er im Amt wäre nichts neu entwickelt werden und schon gar nichts Neues auf Produktion deployed werden würde. Was auch immer die Entwickler machen würden wäre ihm egal, Hauptsache nichts an der von ihm verantworteten Anwendung. Was für ein Einstieg.<br /></p>
<p><br /></p>
<p>Seine Begründung: die Anwendung sollte schon länger abgelöst werden, in der Nachbarstadt wurde bereits seit zwei Jahren an der Nachfolgelösung gebaut. Er selbst und seine Fachabteilungs-Kollegen würden darum auch nur noch in Teilzeit im Team mitarbeiten, und da jedem Go Live ein von ihnen mit grossem Aufwand manuell durchzuführender fachlicher Test vorausgehen musste, wäre für den einfach keine Zeit vorhanden. Maximal ein Bugfix pro Monat wäre noch irgendwie machbar, mehr nicht.<br /></p>
<p><br /></p>
<p>In diesem scheinbaren Dilemma entdeckten die Entwickler aber auch eine Chance: da sie praktisch nichts mehr entwickeln durften, hatten sie freie Kapazitäten und konnten diese für etwas nutzen, was ihnen der alte, gerade zum Nachfolge-Projekt gewechselte, Product Owner immer zugunsten neuer Features wegpriorisiert hatte: Testabdeckung und Testautomatisierung. Beim nächsten Bugfix sparte die den Fachabteilungs-Kollegen bereits die Hälfte des Testaufwandes ein, beim übernächsten noch mehr.<br /></p>
<p><br /></p>
<p>Anfangs erstaunt und zunehmend begeistert liess der Product Owner nach und nach seine Blockade-Haltung fallen. Angesichts der plötzlich mit geringerem Aufwand machbaren Releases liess er sich nicht nur auf eine Weiterentwicklung der Altanwendung ein, er hatte auch eine Idee was noch zu tun wäre. Das System war noch nicht an die Auswirkungen einiger neuer regulatorischer Vorgaben angepasst, wodurch regelmässige Strafzahlungen fällig wurden. Diese Anpassungen wollte er jetzt nachholen.<br /></p>
<p><br /></p>
<p>In wenigen Sprints war auch das geschafft, und das gerade rechtzeitig, da sich plötzlich eine neue Möglichkeit für zusätzlichen Umsatz und Gewinn ergeben hatte. Ein anderes Unternehmen hatte eine Vertriebspartnerschaft angeboten, für die lediglich eine neu zu programmierende Schnittstelle und einige Datenbankanpassungen nötig waren. Erneut waren nur wenige Sprints nötig um diese fertigzustellen. Der Product Owner und seine Fachabteilungs-Kollegen waren euphorisch.<br /></p>
<p><br /></p>
<p>Weniger euphorisch war das Nachfolgeprojekt, das übrigens aus einem SAFe-Release Train bestand. Die Vertriebspartnerschaft sollte natürlich auch mit dem neuen System möglich sein, weshalb plötzlich dessen Umfang erweitert und dessen Zeitplan angepasst werden musste. Leicht säuerlich eskalierte der Projektleiter (der erwähnte ehemalige PO) bei der Geschäftsleitung, um ab jetzt zu verhindern, dass neue Weiterentwicklungen der Altanwendung die Erstellung der Nachfolgelösung aufwändiger machten.<br /></p>
<p><br /></p>
<p>Zum Glück befanden sich im Backlog des Altanwendungsteams noch weitere Aufgaben. Ein vergangener Penetrationstest hatte potentielle Sicherheitslücken identifiziert, die jetzt geschlossen werden konnten. Zum nächsten Sprint Review wurden die Beauftragten für IT-Security und Datenschutz eingeladen, die gleichzeitig begeistert und erbost waren. Begeistert wegen der Verbesserungen, erbost weil sie inzwischen erfahren hatten, dass diese Lücken auch in der Nachfolgelösung vorhanden waren.<br /></p>
<p><br /></p>
<p>Die weitere Geschichte kann man sich denken: das Nachfolgeprojekt musste erneut Scope und Zeitplan anpassen, das Altanwendungs-Team hatte Zeit für weitere Refactorings und Prozessautomatisierungen und konnte dadurch immer schneller andere, schon lange gewünschte Features einbauen, die das Nachfolgeprojekt dann ebenfalls einplanen musste. Es entstand eine bemerkenswerte Dynamik: das mittlerweile agile Altanwendung-Team konnte vom Ablöse-Projekt kaum noch eingeholt werden.<br /></p>
<p><br /></p>
<p>Als es irgendwann doch dazu kam, und die alte Anwendung abgeschaltet werden konnte, hatte sich die Wahrnehmung des Teams durch die Organisation völlig geändert. Um es mit den Worten des Product Owners zu sagen: "Nicht nur das alte System, auch die alten Entwickler waren von allen schon abgeschrieben worden. Nach dieser unglaublichen Wiederauferstehung reissen sich jetzt alle darum, sie zu sich in die neuen Teams zu holen. Was für eine Erfolgsgeschichte."<br /></p>
<p><br /></p>
<p>Das wirklich Bemerkenswerte daran: dieser Erfolg beruhte auf keinem Wunder, sondern auf Ideen, die in jeder agil arbeitenden Firma Common Sense sein sollten: ein kleines, crossfunktionales Team, Automatisierung repetitiver Tätigkeiten, enge Zusammenarbeit mit dem Kunden, möglichst schnelles Reagieren auf geänderte Rahmenbedingungen und kontinuierliche Optimierung. Mit anderen Worten: auch andere Teams könnten sich so entwickeln, wenn man ihnen die richtigen Rahmenbedingungen und Freiheiten gibt. Man müsste es nur tun.<br /></p>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-62529247228798287622024-02-13T09:30:00.001+01:002024-02-13T09:30:00.142+01:00Generative AI in a Nutshell<p>Wenn es um "Agile Erklärvideos" geht ist <a href="https://www.youtube.com/user/henrikkniberg" target="_blank">Henrik Kniberg</a> eine Person auf die immer verwiesen wird. Von ihm sind unter anderem die Videos zum so genannten <a href="https://www.youtube.com/watch?v=Yvfz4HGtoPc" target="_blank">Spotify</a> <a href="https://www.youtube.com/watch?v=vOt4BbWLWQw" target="_blank">Model</a> und das zu Recht legendäre <a href="https://www.lean-agility.de/2017/06/agile-product-ownership-in-nutshell.html" target="_blank">Agile Product Ownership in a Nutshell</a>. Sein neuestes Werk, "Generative AI in a Nutshell" ist daher bereits mit Vorschuss-Lorbeeren begleitet veröffentlicht worden, wie man hier sehen kann zu Recht. Es ist die vermutlich beste Erklärung des aktuellen Standes dieser bemerkenswerten Technologie.<br /></p>
<p><br /></p>
<iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/2IK3DFHRFfw?si=mQeXhzE4o_aoRtKC" title="YouTube video player" width="560"></iframe>
<p><br /></p>
<p>Was man aus diesem Video mitnehmen kann, sind sowohl das Wissen um die Funktionsweise und das Potential der so genannten <a href="https://en.wikipedia.org/wiki/Large_language_model" target="_blank">Large Language Models</a> (LLM), zu denen u.a. <a href="https://chat.openai.com" target="_blank">Chat GPT</a> und <a href="https://gemini.google.com/" target="_blank">Bard/Gemini</a> gehören, als auch das Wissen um deren Begrenzungen und Risiken. Wie Kniberg selber sagt: richtig eingesetzt können sie zu immensen Effizienz- und Effektivitäts-Gewinnen führen, unbedacht eingesetzt können sie massive Schäden anrichten (<a href="https://www.lean-agility.de/2024/01/dunning-kruger-ki.html" target="_blank">siehe hier</a>). Mit KI-Anwendungen umgehen zu können ist daher gerade in Berufen der Wissensarbeit eine entscheidende Qualifikation.<br /></p>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-91901205805611951732024-02-08T09:27:00.018+01:002024-02-08T09:27:00.131+01:00Larman's Law (II)<div style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj36KwXEseLBXzq73mM3cRqrvZs9fqHai7zdlkWQR8sJdTEs-SluvpQ4Fkb4KBhEouN8TeGQwDXrRSVXk7Pn0URu_H2eOXDXuaPhwn8MXPhxc7B4b4f_89L6bYoNI4ZagxiJ7nz1SyQRhdebRho1kOdJHClMC4dsM-bI_f-DiEGT_GOGF-MJJ87Vlavn3NX/s1024/Agile%20Dictionary.jpg" style="display: block; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="640" data-original-width="1024" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj36KwXEseLBXzq73mM3cRqrvZs9fqHai7zdlkWQR8sJdTEs-SluvpQ4Fkb4KBhEouN8TeGQwDXrRSVXk7Pn0URu_H2eOXDXuaPhwn8MXPhxc7B4b4f_89L6bYoNI4ZagxiJ7nz1SyQRhdebRho1kOdJHClMC4dsM-bI_f-DiEGT_GOGF-MJJ87Vlavn3NX/w640-h400/Agile%20Dictionary.jpg" width="640" /></a></div>
<p>Mit der Zeit haben sich viele Menschen Gedanken über die ungeschriebenen
Gesetze der Organisationsentwicklung gemacht und versucht sie (auf
manchmal seriöse, manchmal aber auch eher zynische Art) auf Papier zu
bringen. Besonders produktiv war dabei Craig Larman, der Erfinder von <a href="https://www.lean-agility.de/2022/03/less.html" target="_blank">LeSS</a>, der insgesamt <a href="https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior" target="_blank">fünf Gesetze</a> verfasst hat, die er <i>Larman's Laws of Organizational Behavior</i> genannt hat. Heute soll es hier um das Zweite von ihnen gehen. Es lautet:</p>
<p><br /></p>
<p><i>[...] any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo</i></p>
<p><br /></p>
<p>Dieses zweite "Gesetz" baut auf das erste auf, demzufolge große Organisationen implizit darauf optimiert sind, den Ist-Zustand der
bestehenden Management-, Spezialisten- und Machtpositionen zu erhalten (<a href="https://www.lean-agility.de/2023/12/larmans-law-i.html" target="_blank">mehr dazu hier</a>). Man erkennt, dass beide durch einen eher pessimistischen und polemischen Blick Larmans auf das Veränderungsmanagement geprägt sind. Aber ist diese Sichtweise auch gerechtfertigt, und das vor allem in dieser Absolutheit?<br /></p>
<p><br /></p>
<p>Einen Hinweis darauf wie sie zu verstehen ist findet man in den Erläuterungen, die Larman's Gesetzen angehängt wurden (<a href="https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior" target="_blank">siehe hier</a>). In ihnen führt er aus, dass Kultur, Verhalten und geistige Haltungen in grossen Organisationen durch das Systemdesign (also die Hierarchien, Prozesse, etc.) geprägt werden. Umgekehrt bedeutet das, dass Kultur, Verhalten und Haltungen ohne gleichzeitige Arbeit am System nicht erfolgreich geändert werden können, sondern immer wieder in alte Muster zurückfallen werden.<br /></p>
<p><br /></p>
<p>Und genau das ist es, was Larmans zweites Gesetz aussagt. Ohne eine Veränderung der beeinflussenden Systemfaktoren wird jedes lediglich auf Kultur oder Mindset ausgerichtete Veränderungsvorhaben nicht nur wirkungslos bleiben, sondern durch eben jene Faktoren so lange (unbewusst) umgeformt werden, bis es ein Ergebnis hervorbringt, das dem Ausgangszustand entspricht. Was bleibt sind die neuen Begriffe, hinter denen aber wieder die alten Inhalte stehen.<br /></p>
<p><br /></p><p>Mit diesem Gedanken im Hintergrund kann Larmans zweites Gesetz aber auch eine Anleitung zum erfolgreichen Veränderungsmanagement sein: erkenne, welche Systemfaktoren definierend für die Unternehmenskultur und die individuellen Haltungen der Mitarbeiter sind, und eine Kulturveränderung wird durch eine Arbeit am System möglich - und das wenn man möchte sogar ohne dass irgendwelche neuen Namen für Titel, Prozesse, etc. eingeführt werden.</p>
<p><br /></p>
<p>Natürlich sollte dazu noch erwähnt werden, dass eine derartige Arbeit am System hochkomplex und in ihren Ergebnissen nicht immer vorhersehbar ist, aber das ist eine Geschichte für ein anderes mal.<br /></p>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-6377762031069795922024-02-05T09:30:00.002+01:002024-02-05T12:23:02.448+01:00KVP im Bürgeramt<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQH1di5FRhPO4ZWcGuIweJFNdGsOJi_bpT_2yW4C0u1whGTLg8k8i8ezPiJY0KqgKBrF2u5Y9CuO52F97IILzbwhMukftBRA6PxCephuyt3-CP_sIvLlxWZfpGFRw7ZBs5xugzIg4PSfbzNoDY6ILCw-jxYOHdg8sA3yuKowGOFIRBgjBlrr9j0Npumsda/s1200/Termin-Checkin.jpg" style="display: block; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="688" data-original-width="1200" height="366" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQH1di5FRhPO4ZWcGuIweJFNdGsOJi_bpT_2yW4C0u1whGTLg8k8i8ezPiJY0KqgKBrF2u5Y9CuO52F97IILzbwhMukftBRA6PxCephuyt3-CP_sIvLlxWZfpGFRw7ZBs5xugzIg4PSfbzNoDY6ILCw-jxYOHdg8sA3yuKowGOFIRBgjBlrr9j0Npumsda/w640-h366/Termin-Checkin.jpg" width="640" /></a></div>
<p>Zu meinen Lieblingsbeispielen für kontinuierliche Verbesserungsbemühungen zählen Einrichtungen, die man damit nicht sofort assoziieren würde: deutsche Behörden. Optimiert wird auch in ihnen, und da man sie nur in relativ grossen Abständen aufsucht, ist die Chance gross, dass einem jedesmal irgendetwas auffällt, das anders ist als beim letzten mal. In meinem Fall sind es die Bürgerämter meiner Wohnorte (z. Zt der Stadt Bonn), in denen ich etwa einmal pro Jahr erscheinen muss.<br /></p>
<p><br /></p>
<p>Bevor wir zu meinen Beobachtungen kommen, macht zuerst eine kurze Erläuterung zu dem "Verbesserungsgegenstand" Sinn: das was im Bürgerzentrum regelmässig optimiert wird, ist der Durchfluss von Kunden, also Bürgern, die für irgendeinen Verwaltungsakt dort vorstellig werden müssen. Um diesen eine möglichst gute Service-Erfahrung zu geben, und um die Servicekräfte optimal auszulasten, sollten Staus und Wartezeiten so gering wie möglich sein.<br /></p>
<p><br /></p>
<p>In der weit zurückliegenden Anfangszeit der Optimierungen war das noch nicht der Fall. Jeder der mit einem Termin oder als Laufkundschaft zur Stadt kam meldete sich an, setzte sich in einen Warteraum und wartete dort darauf, dass der eigene Name aufgerufen wurde. Wie lang das dauern würde liess sich nicht absehen, Wartezeiten von über einer Stunde waren nicht selten. Diese Unklarheit über die verbleibende Wartezeit war das erste, das durch eine Prozessanpassung behoben wurde.<br /></p>
<p><br /></p>
<p>Irgendwann wurden Wartenummern eingeführt, zu Beginn noch solche in Papierform, die man sich aus einem vor Ort stehenden Automaten ziehen musste. Aufgerufen wurden jetzt nicht mehr die Namen sondern die Nummern, wodurch sich erkennen liess, wie viele andere Personen vor einem selbst bedient werden würden. Liess sich so erkennen, dass es noch dauern würde, konnte man kurz vor die Tür gehen, Geld in die Parkuhr werfen, etwas rauchen oder sonstige kurze Erledigungen machen.<br /></p>
<p><br /></p>
<p>Der nächste Verbesserungsschritt war die Einführung grosser Bildschirme, auf denen die zuletzt aufgerufenen Nummern angezeigt wurden. Für den Fall, dass man verspätet eintraf oder den eigenen Aufruf überhört hatte, konnte man dort sehen, dass man bereits an der Reihe war. Eine darauf aufbauende Verbesserung bestand daraus, dass dort auch die Tischnummer der nächsten freien Servicekraft angezeit wurde, wodurch der bis dahin nötige Gang zum Zentralschalter entfiehl.<br /></p>
<p><br /></p>
<p>Die hinter der Anzeigetafel arbeitende Software wurde später mit einer weiteren verbunden, mit der man Terminbuchungen online vornehmen konnte. Sobald man einen Termin gebucht hatte erhielt man eine Mail. in der nicht nur die Terminbestätigung stand, sondern auch die Wartenummer. Vor Ort musste man dadurch nicht mehr eine Nummer ziehen und warten, sondern konnte direkt überprüfen, ob man bereits aufgerufen wurde.<br /></p>
<p><br /></p>
<p>Die vorerst letzte Optimierung, die mir bei meinem letzten Besuch aufgefallen ist, besteht darin, dass man jetzt vor Ort grosse Touch-Displays hat, auf denen man durch Eingabe seiner online gebuchten Wartenummer mitteilen kann, dass man angekommen ist und aufgerufen werden kann. Verspätungen sind dadurch kein Problem mehr, man rutscht stattdessen weiter nach hinten in die Reihenfolge, aus der zuerst andere Nummern aufgerufen und bedient werden können.<br /></p>
<p><br /></p>
<p>Weitere Prozessverbesserungen dürften in diesem Zeitraum auch ausserhalb des für die Kunden sichtbaren Bereichs stattgefunden haben, alleine <a href="https://www.lean-agility.de/2021/01/digitalisierung-v.html" target="_blank">im Bereich der Digitalisierung</a> kann man sich so einiges vorstellen. Über die Jahre wird es so zu einem ingesamt beachtlichen Umfang von Veränderungen gekommen sein. <br /></p>
<p><br /></p>
<p>Diese Art der nach und nach stattfindenden Optimierung hat mehrere Vorteile gehabt: grosse, disruptive Veränderungen wurden unnötig, die Folgen der jeweils letzten Umstellung liessen sich aufgrund der kleinen Umfänge besser identifizieren und bewerten, und in Summe ist es so zu einem Prozess gekommen, der nicht nur gut funktioniert, sondern auch einer ist, auf den beim Versuch alles im Voraus zu planen vielleicht niemand gekommen wäre.<br /></p>
<p><br /></p>
<p>Zuletzt hat der KVP (Kontinierliche Verbesserungsprpzess) im Bürgeramt noch einen Vorteil auf der Meta-Ebene: er hat an einem Ort stattgefunden, den jeder Mensch in Deutschland kennt, ins Bürgeramt muss früher oder später jeder. Es ist damit ein Praxisbeispiel das sofort jeder nachvollziehen kann und anhand dessen man Prozessoptimierungen auch für Menschen, die selten damit zu tun haben, nachvollziebar erklären kann.<br /></p>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-62682186565183650852024-01-31T09:30:00.001+01:002024-01-31T09:30:00.131+01:00Kommentierte Links (CX)<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBoBRmlz1efocOAdGT0kTPFJ7p1-p312jqD4pgLuqazXz25jySPUEr7D8em2LCLMBYBjcMlSXPXK2vksePu7roJY4OUC_ZzEOCPS9mKQ1IC2McWQONVaiMJ0RmQ15KtrkbORpnoUi0r-fmBveWJkVdu47aooY4In8kyS6CiVlP7os3TGEz1pzykUGZnw/s1000/Links.jpg" style="display: block; margin-left: auto; margin-right: auto; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="666" data-original-width="1000" height="426" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBoBRmlz1efocOAdGT0kTPFJ7p1-p312jqD4pgLuqazXz25jySPUEr7D8em2LCLMBYBjcMlSXPXK2vksePu7roJY4OUC_ZzEOCPS9mKQ1IC2McWQONVaiMJ0RmQ15KtrkbORpnoUi0r-fmBveWJkVdu47aooY4In8kyS6CiVlP7os3TGEz1pzykUGZnw/w640-h426/Links.jpg" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Grafik: <a href="https://pixabay.com/de/illustrations/internet-social-media-netzwerk-blog-4463031/" target="_blank">Pixabay / Geralt</a> - <a href="https://pixabay.com/de/service/license/" target="_blank">Lizenz</a></td></tr></tbody></table>
Das Internet ist voll von Menschen, die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.<br />
<br />
<h3><a href="https://www.faz.net/aktuell/wirtschaft/mehr-wirtschaft/post-in-grossbritannien-700-filialleiter-zu-unrecht-verurteilt-17807158.html" target="_blank">Philip Plickert: Hunderte Menschenleben durch einen Computerfehler ruiniert</a><br /></h3>
Vor einigen Jahren hatte ich ab und zu auch Meldungen in die Kommentierten Links aufgenommen, in denen es um dramatische Folgen von Software-Fehlern ging, z.B. <a href="https://www.lean-agility.de/2015/05/kommentierte-links.html" target="_blank">um Flugzeugabstürze</a> oder um die <a href="https://www.lean-agility.de/2015/12/kommentierte-links-viii.html#Inslee" target="_blank">versehentliche Entlassung von Verbrechern</a> aus Gefängnissen. Diese Nachricht hier ist so krass, dass ich diese Kategorie wieder aufleben lasse: 700 Leiter von britischen Postfilialen wurden aufgrund fehlerhafter Software zu Unrecht wegen Unterschlagung verurteilt, einige davon zu Gefängnisstrafen. Berufliche Existenzen wurden zerstört, Reputationen ruiniert, Ehen gingen in die Brüche. Irrsinnig.<br />
<br />
<h3><a href="https://krautreporter.de/5190-wir-haben-unsere-arbeitsweise-radikal-verandert" target="_blank">Bent Freiwald: Wir haben unsere Arbeitsweise radikal verändert</a></h3>
Eine Fallstudie zu selbstorganisiertem Arbeiten, die anders ist als die meisten von denen man sonst so hört, alleine weil der Kontext ein anderer ist als der übliche (IT-Abteilungen, Krankenpfleger, etc). Die Gruppe um die es hier geht ist die Redaktion des Online-Magazins <a href="https://krautreporter.de" target="_blank">Kraureporter</a>, in dem alle leitenden Positionen abgeschafft wurden. Stattdessen arbeiten in einem entfernt auf Scrum basierten Arbeitsmodus drei Teams an der Recherche und dem Verfassen von Texten, übergreifende Entscheidungen werden in einem strukturierten Beteiligungsverfahren getroffen. Spannend zu lesen, von solchen Experimenten würde ich gerne mehr hören.<br />
<br />
<h3><a href="https://www.scrum.org/resources/blog/coaching-secret-stop-being-so-helpful" target="_blank">Stephanie Ockerman: Stop Being So "Helpful"</a><br /></h3>
Völlig zu Recht beschreibt Stephanie Ockermann ihre Beobachtung als eines der schmutzigen Geheimnisse vieler Agile Coaches: wenn sie das Gefühl haben, ihren Teams helfen zu können, indem sie ihnen bestimmte Herausforderungen abnehmen, dann tun sie das - und untergraben damit die Selbstorganisation und Problemlösungskompetenz ihrer Coachees. Dieses Verhalten ist gut gemeint und menschlich, trotzdem ist es eines das man sich abgewöhnen sollte, sobald man es an sich selbst entdeckt. Der Text enthält auch eine kleine Anleitung dazu, wie man es entdecken kann und wie man sich selbst zu mehr Zurückhaltung bringt.<br />
<br />
<h3><a href="https://jeffgothelf.com/blog/what-people-say-vs-what-they-do/" target="_blank">Jeff Gothelf: What people say vs what they do</a></h3>
Apropos Beobachtungen allzu menschlichen Verhaltens. Auch Jeff Gothelf hat eine solche gemacht, und zwar die, dass das was Menschen sich vornehmen und das was sie dann tun sehr weit auseinanderliegen können, allerdings nicht weil sie unaufrichtig sind, sondern weil die Rahmenbedingungen sich so unerwartet entwickeln können, dass ein anderes Verhalten als das ursprünglich geplante plötzlich viel naheliegender ist. Ein Fall den er besonders hervorhebt, ist die in Kundeninterviews erfragte Bereitschaft neue Funktionen zu nutzen. Die sollte anders validiert werden als durch eine blosse Absichtserklärung, wenn sie eine Aussagekraft haben soll.<br />
<br />
<h3><a href="https://agilemasteryinstitute.com/blog/agility-is-certainly-not-dead/" target="_blank">Geoff Watts: Agility is certainly not dead</a></h3>
Eines der grossen Themen dieses Winters ist das (mal wieder) von einigen Menschen marktschreierisch vorgetragene Ende der agilen Bewegung. Geoff Watts versucht zu ergründen was hinter diesen Aussagen steckt und trägt einige Gründe zusammen: mit Missverständnissen verknüpfte falsche Hoffnungen, die Versuche die agilen Frameworks an Stellen einzusetzen an denen sie gar keinen Sinn machen und die über das Ziel hinausgeschossene Kommerzialisierung. Gleichzeitig streicht er heraus, dass die Gründe wegen denen die agilen Vorgensweisen nötig geworden sind unverändert weiter existieren, und agiles Arbeiten (unter welchem Namen auch immer) weiter nötig machen. Passend dazu: <a href="https://medium.com/the-liberators/agile-is-dead-%EF%B8%8F-5e7590466611" target="_blank">ein Artikel von Barry Overeem</a>, in dem er beschreibt, wie man sich aus den "Agile is Dead"-Debatten befreien kann.<br />Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-29556020893232363662024-01-29T09:30:00.076+01:002024-01-29T23:28:00.755+01:00Warum so viele Manager?<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEixdglDHTUXDQUYGF6Vjyziizz7hQ2VdT-B3siwpJfqQNuMGVi0TOG_BATURDu8EJN5llkbdGiAiZEizRi1pV9yKeAi9VAL5_8y68R39m84yXodUnEX7bwhz1Ycbts_trVYlk_wlQ70xCtDOnUqhsz1MbdlqyCtWMClSAcPS74Fdw5x83WquDqkKc-gDoKi/s640/Office.jpg" style="display: block; margin-left: auto; margin-right: auto; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="457" data-original-width="640" height="456" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEixdglDHTUXDQUYGF6Vjyziizz7hQ2VdT-B3siwpJfqQNuMGVi0TOG_BATURDu8EJN5llkbdGiAiZEizRi1pV9yKeAi9VAL5_8y68R39m84yXodUnEX7bwhz1Ycbts_trVYlk_wlQ70xCtDOnUqhsz1MbdlqyCtWMClSAcPS74Fdw5x83WquDqkKc-gDoKi/w640-h456/Office.jpg" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Bild: <a href="https://www.loc.gov/item/2018747147/" target="_blank">Gottscho-Schleisner / Library of Congress</a> - <a href="https://creativecommons.org/publicdomain/mark/1.0" target="_blank">Public Domain</a><br /></td></tr></tbody></table>
<p>Eine der Nachrichten, die in letzter Zeit für Aufmerksamkeit gesorgt haben, ist der bevorstehende Stellenabbau bei Bayer. Nicht nur wegen der verlorenen Arbeitsplätze, sondern auch wegen einer <a href="https://www.n-tv.de/wirtschaft/Der-Bayer-Chef-schwingt-die-Job-Axt-article24672010.html" target="_blank">in diesem Zusammenhang veröffentlichten Zahl</a>: 17.000 von 100.000 Mitarbeitern arbeiten dort im Management, also fast jeder fünfte. Mehrfach habe ich die Frage gehört, wie das denn sein kann, die Zahl wirkt auf den ersten Eindruck unglaublich hoch. Versuchen wir es mit einer Erklärung.<br /></p>
<p><br /></p>
<p>Da ich die internen Strukturen bei Bayer nicht kenne, starten wir mit Vergleichswerten, die ich in verschiedenen anderen Firmen erlebt habe. Auf der untersten Ebene gehen wir dabei von Teams, Gruppen oder Referaten von ca. 10 Mitarbeitern aus, einer häufig anzutreffende Grösse. Unterstellen wir, dass jede dieser Einheiten einen eigenen Team-, Gruppen oder Referatsleiter hat, kommen wir damit auf ein Manager/Mitarbeiter-Verhältnis von 1 zu 10.<br /></p>
<p><br /></p>
<p>Auf der nächsthöheren Ebene gehen wir davon aus, dass jeweils fünf der
untersten Einheiten eine Abteilung bilden, jeweils fünf Abteilungen einen Bereich, und so weiter, bis hinauf zu den Ressorts und Landesgesellschaften. Jede dieser Einheiten hat einen Leiter, und nicht nur das, ab einer bestimmten Grösse kommen Stellvertreter und Stabsstellen dazu. Alle diese Positionen zählen wir auch zum Management, und gehen dadurch grob von einem Manager/Mitarbeiter-Verhältnis von 1 zu 9 aus.</p>
<p><br /></p>
<p>Dieses Verhältnis dürfte vor allem dort anzutreffen sein, wo es um gleichbleibende Regeltätigkeiten geht, z.B. in der Fertigung oder einem Callcenter. In der Wissens- oder Innovationsarbeit ist es aber meistens komplizierter, dort wird normalerweise in Projekten gearbeitet. Diese Projekte bilden dabei eine eigene, zu den Teams, Abteilungen, etc. parallele Organisation, die sich die Mitarbeiter von den gerade genannten Einheiten leiht, zu deren Koordination aber eigene Manager hat.<br /></p>
<p><br /></p>
<p>Gehen wir auch hier zuerst von der Grösse von 10 Mitarbeitern aus, die zu einem gemeinsamen Teilprojekt gehören.<sup>1</sup> Und nehmen wir an, dass fünf Teilprojekte ein Projekt bilden und fünf Projekte ein Programm. Wenn wir jetzt noch davon ausgehen, dass wiederum jede dieser Einheiten einen Teilprojekt-, Projekt- oder Programmleiter hat (und die Linienmanager einbeziehen), kommen wir in den projektartig arbeitenden Teilen der Organisation auf ein Manager/Mitarbeiter-Verhältnis von 1 zu 5 oder 1 zu 4.</p>
<p><br /></p>
<p>Auch hier kommen aber nochmal zusätzliche Management-Positionen dazu, zum einen erneut die Stellvertreter und Stabsstellen, ausserdem aber noch die Project Management Offices (PMO), in denen sich bemerkenswerte Mengen von Menschen mit Planungen, Schätzungen, Anträgen, Genehmigungen oder Kommunikation beschäftigen können. Dazu kommen funktionale Stellen wie z.B. Qualitäts-Manager, Rollout-Manager, Compliance-Manager, etc.<br /></p>
<p><br /></p>
<p>Am Ende kann durch diese doppelte Management-Hierarchie in Linien- und Projektorganisation in den projektartig arbeitenden Teilen der Firma sogar ein Manager/Mitarbeiter-Verhältnis von 1 zu 3 möglich sein (!). Verrechnen wir das mit den weniger Management-lastigen Regeltätigkeits-Einheiten, ist im Gesamtdurchschnitt ein Verhältnis möglich, dass etwa dem entspricht, von dem bei Bayer berichtet wurde, etwa 1 zu 5. Diese Zahl kann also stimmen.<sup>2</sup><br /></p>
<p><br /></p>
<p>Spätestens jetzt stellt sich die Frage, was all diese Manager eigentlich machen. Wenn wir die zahlenmässig kleine Gruppe der strategisch lenkenden Topmanager ausklammern, lautet die Antwort, dass sie vor allem kommunizieren und koordinieren. Kommuniziert werden Ziele (incl. deren Herunterbrechung) und Ergebnisse (incl. deren Zusammenfassung), koordiniert werden Abhängigkeiten, v.a. fachlicher und technischer Natur, aber auch die zu anderen planenden, freigebenden oder budgetierenden Einheiten.</p>
<p><br /></p>
<p>Wichtig für das Verständnis ist dabei, dass es in der Regel ein Systemdesign gibt, dass diese Tätigkeiten tatsächlich zu Vollzeitjobs macht. Häufige Faktoren sind z.B. hohe Spezialisierungen und knappe Budgets, wodurch Mitarbeiter nur in Teilzeit in die Projekte entsandt werden können, was zu permanenten Ziel-, Termin- und Loyalitätskonflikten führt, deren Auflösung und deren zu kommunizierende Konsequenzen bei Linien- und Projektmanagern erhebliche Daueraufwände verursachen.<br /></p>
<p><br /></p>
<p>Daraus ergibt sich auch, was zu tun ist, wenn man das Verhältnis von Managern zu Mitarbeitern verringern will. Zum einen müssen die unteren Einheiten crossfunktionaler und durch breitere Skillprofile in Vollzeit besetzbar werden, so dass die Zahl der zu koordinierenden Abhängigkeiten abnimmt,<sup>3</sup> zum anderen müssen diese Einheiten mehr Entscheidungskompetenzen bekommen, wodurch es nicht mehr nötig ist, ihnen ihre Aufgaben aus übergreifenden Zielen abzuleiten (das können sie dann selbst).<br /></p>
<p><br /></p>
<p>In einem solchen Setting kommt eine Organisation auch mit deutlich weniger Managern aus, wobei allerdings zu beachten ist, dass eine Delegation von Verantwortung nach unten ohne Begleitung und Befähigung schnell in Überforderung enden kann (<a href="https://www.lean-agility.de/2021/04/die-autonomie-falle.html" target="_blank">die so genannte Autonomiefalle</a>). Um diese zu vermeiden müssen die verbleibenden Manager verstärkt die Rolle von Beratern und Coaches annehmen, um so die neuen, crossfunktional-autonomen Teams in Richtung Selbstmanagement zu entwickeln. <br /></p>
<p><br /></p>
<p>Genau das ist laut dem oben verlinkten Artikel auch das Zielbild der organisatorischen Veränderungen bei Bayer. Wir können gespannt sein ob das erfolgreich sein wird oder nicht, vielleicht wird es ja in einigen Monaten oder Jahren neue Berichte in den Medien geben, aus denen sich das Ausmass der Erfolge ablesen lassen wird. <br /></p>
<p><br /></p>
<p><br /></p>
<span style="font-size: xx-small;"><sup>1</sup>Bzw. <a href="https://en.wikipedia.org/wiki/Full-time_equivalent" target="_blank">FTEs</a>, also Entsprechungen einer Vollzeitstelle, die ggf. auf mehrere Teilzeitstellen aufgeteilt werden können<br />
<sup>2</sup>Natürlich gibt es auch viele Unternehmen in denen die Zahlen andere sind, aus meiner Erfahrung sind die von Bayer aber zumindest keine totalen Ausreisser<br />
<sup>3</sup>Ein gewisser Umfang von Abhängigkeiten ist zwar unvermeidbar, wird der klein gehalten, können die Teams diese aber auch selbst managen<br /></span>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-26369493196630911052024-01-25T09:30:00.008+01:002024-01-25T09:30:00.130+01:00MBO und OKR<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQpzFrLecTC-2p5FI3rmy5IEFxHFZSamXZ4I2KhOSPmeilOBHlLfeLbSSxS9ETI5sKaOLPXC4vGrQDIRNB_vZwaBDmf_9ezNjjjBcQy_cwMzfzzpvBsskKC_V1QwKXqWawhQx-ES1fskwabWtoR6mFaxU3J9kKC43DhdjCkuCN3tF2tQgI_Td5fpe-D8rp/s1024/MBOKR.jpg" style="display: block; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="640" data-original-width="1024" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQpzFrLecTC-2p5FI3rmy5IEFxHFZSamXZ4I2KhOSPmeilOBHlLfeLbSSxS9ETI5sKaOLPXC4vGrQDIRNB_vZwaBDmf_9ezNjjjBcQy_cwMzfzzpvBsskKC_V1QwKXqWawhQx-ES1fskwabWtoR6mFaxU3J9kKC43DhdjCkuCN3tF2tQgI_Td5fpe-D8rp/w640-h400/MBOKR.jpg" width="640" /></a></div>
<p>Zu den grossen "agilen Trends" der letzten Jahre gehören die <i>Objectives and Key Results</i> (OKRs), eine Methode um persönliche oder übergreifende Ziele, von der man sich einen einfacheren oder besseren Weg zur Agilität erhofft. Die damit erzielten Ergebnisse schwanken allerdings stark, von deutlichen Verbesserungen bis deutlichen Verschlechterungen ist alles dabei. Meine steile These dazu: man kann absehen was davon der Fall sein wird, und dafür muss man nur betrachten wie vorher mit einem anderen Ansatz umgegangen worden ist - dem <i>Management by Objectives</i> (MBO).<br /></p>
<p><br /></p>
<p>Bevor wir darauf eingehen eine kurze Begriffsbestimmung. OKRs wurden von <a href="https://en.wikipedia.org/wiki/Andrew_Grove" target="_blank">Andrew Grove</a> bei Intel entwickelt und von seinem damaligen Mitarbeiter <a href="https://en.wikipedia.org/wiki/John_Doerr" target="_blank">John Doerr</a> später bei Google eingeführt und dadurch popularisiert. Sie teilen Ziele in qualitative <i>Objectives</i> und quantitative<i> Key Results</i> auf, von denen die ersten abstrakt-übergreifend und die zweiten davon abgeleitet und konkret überprüfbar sind. In der Umsetzung werden Objectives quartalsweise gesetzt und durch Key Results nach und nach erreicht.<br /></p>
<p><br /></p>
<p>Dass dieser Ansatz flexibler (und agiler?) als die sonst üblichen starren Jahresziele ist, liegt auf der Hand, und tatsächlich ist er als bewusste Weiterentwicklung, bzw. Ablösung eines Vorgehensmodells entwickelt worden, mit dem diese in den meisten Fällen umgesetzt werden, eben dem MBO. Grove und Doerr weisen in ihren Büchern <a href="https://www.penguinrandomhouse.com/books/72467/high-output-management-by-andrew-s-grove-former-chairman-and-ceo-of-intel/#" target="_blank">High Output Management</a> (Grove, 1983) und <a href="https://www.whatmatters.com/the-book" target="_blank">Measure what Matters</a> (Doerr, 2017) explizit auf diese Art der Entstehung hin.<br /></p>
<p><br /></p>
<blockquote><div>[Before the introduction of OKRs], goals were centrally planned and sluggishly trickled down the hierarchy. At others, they became stagnant for lack of frequent updating; or trapped and obscured in silos; or reduced to key performance indicators (KPIs), numbers without soul or context. Most deadly of all, MBOs were commonly tied to salaries and bonuses.<br /></div><div style="text-align: right;">
Andy Grove: High Output Management, S.25</div></blockquote>
<p><br /></p>
<p>Besonders der letzte Punkt ist dabei erwähnenswert, da er den durch ihre Langfristigkeit immer realitätsferner werdenden MBOs eine destruktive Dynamik hinzufügt: die Koppelung der Zielerreichung an Gehaltsbestandteile. Es ist eine menschliche, bzw. betriebswirtschaftliche Reaktion - um den vollen Bonus ausgezahlt zu bekommen, werden alle Ziele konsequent umgesetzt, und zwar auch dann wenn sie mittlerweile als unsinnig erkannt wurden. Geld sticht Sinn.<br /></p>
<p><br /></p>
<p>Die Rollen sind damit klar verteilt. Alt und neu, überkommen und modern, starr und flexibel, Objectives and Key Results und
Management by Objectives. Wie fast immer bei derartig klaren Gegensätzen gilt aber auch hier, dass sie zu einfach sind um wahr zu sein. Betrachtet man das Buch in dem die MBOs erstmals beschrieben wurden, <a href="https://www.harpercollins.com/products/the-practice-of-management-peter-f-drucker" target="_blank">The Practice of Management</a>, geschrieben 1954 vom österreichisch-amerikanischen Ökonomen <a href="https://de.wikipedia.org/wiki/Peter_Drucker" target="_blank">Peter Drucker</a>, entdeckt man Erstaunliches.<br /></p>
<p><br /></p>
<blockquote><div>The most effective managers I know [...] have each of their subordinates write a “manager’s letter” twice a year. In this letter to his superior, each manager first defines the objectives of his superior’s job and of his own job as he sees them. He then sets down the performance standards which he believes are being applied to him. Next, he lists the things he must do himself to attain these goals—and the things within his own unit he considers the major obstacles. He lists the things his superior and the company do that help him and the things that hamper him. Finally, he outlines what he proposes to do during the next year to reach his goals.<br /></div><div style="text-align: right;">
Peter Drucker: The Practice of Management, S. 343</div></blockquote>
<p><br /></p>
<p>Mit anderen Worten: das was OKRs ausmacht und es angeblich von den MBOs unterscheidet ist in diesen bereits enthalten. Die dezentrale Planung, die Trennung von Zielen und Ergebnissen, die Möglichkeit zu Anpassungen während des Jahres, all das war von Drucker bereits so angedacht. Und selbst die durch die Knüpfung an Gehaltsbestandteile durchgeführte Steuerung von oben war nicht in seinem Sinn, stattdessen spach er bewusst von <i>Management by Objectives and Self-Control</i>.<br /></p>
<p><br /></p>
<blockquote><div>Reports and procedures should be the tool of the man who fills them out. They must never themselves become the measure of his performance.<br /></div><div style="text-align: right;">
Peter Drucker: The Practice of Management, S. 359</div></blockquote>
<p><br /></p>
<p>Die Betrachtung des MBO wird damit komplett auf den Kopf gestellt - nicht der Ansatz selbst ist problematisch, sondern seine falsche Umsetzung, nicht er selbst beinhaltet Top Down-Management, fehlende Flexibilität und nicht zielführende Anreizgebung, sondern die Menschen die ihn umsetzen bringen diese Ideen mit und überschreiben damit die in ihrem Ursprung komplett in die andere Richtung orientierten Umsetzungs-Empfehlungen.<br /></p>
<p><br /></p>
<p>Und damit kommen wir zurück zur Eingangs-These: will man voraussagen können wie eine Organisation mit Objectives and Key Results klarkommen wird, muss man eigentlich nur überprüfen wie sie mit Management by Objectives umgeht. Setzt sie dieses wie ursprünglich gedacht ein, werden auch OKRs gut funktionieren, verfremdet sie es bis in ihr Gegenteil wird sie das mit grosser Wahrscheinlichkeit auch mit OKRs tun. Da so ziemlich jede halbwegs grosse Firma bewusst oder unbewusst mit MBO arbeitet, ist das eine erstaunlich effektive Art der Überprüfung.<br /></p>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-17228461773809329062024-01-22T09:30:00.030+01:002024-01-22T10:09:34.310+01:00Täglich grüßt das Murmeltier - ungewollte Folgen agilen Managements<p>Als sich abgezeichnet hat, dass ich die Konferenz Manage Agile 23 verpassen werde, war ich enttäuscht, und zwar vor allem aus einem Grund: ich hatte mich auf die Keynote von <a href="https://www.uni-bielefeld.de/fakultaeten/soziologie/fakultaet/personen/kuehl/" target="_blank">Stefan Kühl</a> gefreut, einem Professor der Soziologie und bekannten Beobachter und Kritiker der agilen Bewegung. Aber jetzt ist wieder alles gut, denn <a href="https://summit-community.de" target="_blank">Summit</a> (der Konferenzveranstalter) hat das Video veröffentlicht, und wie erwartet ist es sehenswert und unterhaltsam.<br /></p>
<p><br /></p>
<iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/vLhNT6-8D6k?si=eemw_IqyvVdN8mYF" title="YouTube video player" width="560"></iframe>
<p><br /></p>
<p>Inhalt seiner Ausführungen ist, dass er die Eigenschaften von Management-Moden herausarbeitet und die agile Bewegung auf sie überprüft. Sein Fazit: die Kriterien sind gegeben, Agile ist eine Mode. Und er wagt sogar eine Prognose: in fünf Jahren wird sie vorbei sein. An der Stelle kann man gespannt sein ob er recht behalten wird, nicht zuletzt mit Blick auf die Geschichte: das Ende der Agilität wird seit fast einem Vierteljahrhundert vorhergesagt, ohne das es bisher dazu gekommen ist (und dass ich die Klassifizierung als Management-Mode nicht teile <a href="https://www.lean-agility.de/2021/02/warum-agile-keine-management-mode-ist.html" target="_blank">habe ich bereits woanders aufgeschrieben</a>). Trotz allem: sehens- und hörenswert.<br /></p>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-30997051248149932232024-01-18T09:30:00.003+01:002024-01-25T18:04:56.474+01:00300 agile Zertifizierungen<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRi_S8L3N2WkITxbYPL0elNw7H60-BiKKeGygzp0suCBnZT2xALqYMtWa86CE8gN_LdFUxCf0kqc8VEL4zC7vw4hImF9dORig0jsjCxOtebW_PjRTxXaFBfmsBiAtIIn90FeRi0mYGoQGsDk40kVpiXz8hVCqIrNDyupu8UUEzNkPYki4Z_nbVP5mYyIMx/s1024/Certificates.jpg" style="display: block; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="640" data-original-width="1024" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRi_S8L3N2WkITxbYPL0elNw7H60-BiKKeGygzp0suCBnZT2xALqYMtWa86CE8gN_LdFUxCf0kqc8VEL4zC7vw4hImF9dORig0jsjCxOtebW_PjRTxXaFBfmsBiAtIIn90FeRi0mYGoQGsDk40kVpiXz8hVCqIrNDyupu8UUEzNkPYki4Z_nbVP5mYyIMx/w640-h400/Certificates.jpg" width="640" /></a></div>
Als ich vor einigen Jahren <a href="https://www.lean-agility.de/2020/01/240-agile-zertifizierungen.html" target="_blank">eine Übersicht über die mir bekannten agilen Zertifizierungen</a> erstellt habe, war das im Wesentlichen der Zeitverteib für einige unfassbar langweilige Calls, in denen ich damals sitzen musste. Mit der Zeit hat sie sich dann zu einem Belegstück für den <a href="https://www.lean-agility.de/2021/09/der-agil-industrielle-komplex.html" target="_blank">Agil-Industriellen Komplex</a> entwickelt, durch dessen Zusendung ich bis heute andere Menschen schockieren kann. Da ich gelegentlich danach gefragt wurde ist hier ein Update.<br />
<br />
Wie letztes mal ist es ohne Anspruch auf Vollständigkeit, einige Beobachtungen kann man aber machen. Es sind noch einmal mehr geworden (über 300 statt 240), es sind Anbieter verschwunden und andere sind dazugekommen. Einige Titel befinden sich hart an der Grenze zur Realsatire (z.B. "Scrum Developer Instructor" und "Agile PeopleOps Agility") und einige Zertifizierungsorganisationen haben verwirrend ähnliche Namen (z.B. die Agile Coach Alliance und die Agile Coaches Alliance).<br />
<br />
Eine interessante Entwicklung ist, dass einige Zertifizierungen umbenannt wurden. Man kann spekulieren, dass das letzte mit den Gerichtsprozessen zwischen den verschiedenen Anbietern zu tun hat (am bekanntesten dürfte <a href="https://casetext.com/case/scrum-all-inc-v-scrum-inc" target="_blank">der zwischen Scrum Alliance und Scrum Inc sein</a>), die Teil der Auseinandersetzungen um diesen Millionenmarkt sind. Mal sehen ob es auch bei den ähnlichen Namen der Zertifizierungsorganisationen dazu kommt.<br />
<br />
<table class="tg">
<tbody>
<tr>
<th class="tg-m6jf"><b>Organisation</b></th>
<th class="tg-2fdn"><b>Zertifizierungen</b></th>
<th class="tg-2fdn"><b>Auflistung</b></th>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.icagile.com/" target="_blank">International Consortium for Agile</a></td>
<td class="tg-2fdn">26</td>
<td class="tg-2fdn">
<ul>
<li>Agile Fundamentals</li>
<li>Business Agility Foundations</li>
<li>Leading with Agility</li>
<li>People Development</li>
<li>Enterprise Agile Coaching</li>
<li>Coaching Agile Transformations</li>
<li>Expert in Enterprise Coaching</li>
<li>Agile Team Facilitation</li>
<li>Agile Coaching</li>
<li>Expert in Agile Coaching</li>
<li>Agile Product Ownership</li>
<li>Product Management</li>
<li>Agile Project and Delivery Management</li>
<li>Delivery at Scale</li>
<li>Agile Programming</li>
<li>Agile Software Design</li>
<li>Foundations of DevOps</li>
<li>Implementing DevOps</li>
<li>Agile Testing</li>
<li>Agile Test Automation</li>
<li>Agility in HR</li>
<li>Adaptive Org Design</li>
<li>Agility in Finance</li>
<li>Lean Portfolio Management</li>
<li>Agility in Marketing</li>
<li>Systems Coaching</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://certiprof.com" target="_blank">CertiProof</a></td>
<td class="tg-2fdn">22</td>
<td class="tg-2fdn">
<ul>
<li>Scrum Master Professional Certification</li>
<li>Scrum Product Owner Professional Certification</li>
<li>Scrum Developer Professional Certification</li>
<li>Scrum Advanced Professional Certification</li>
<li>Agile Leader Professional Certification</li>
<li>Agile Coach Professional Certification</li>
<li>Business Agility Professional Certification</li>
<li>Agile HR Certified Professional</li>
<li>User Stories Foundations Certificate</li>
<li>Business Model Canvas Professional Certificate</li>
<li>Design Thinking Professional Certification</li>
<li>Design Sprint Professional Certification</li>
<li>Lean Product Discovery Certification</li>
<li>DevOps Essentials Professional Certification</li>
<li>DevOps Foundation Professional Certification</li>
<li>DevOps Advanced Professional Certification</li>
<li>DevOps Culture Practitioner Certification</li>
<li>DevOps Culture Certified Trainer</li>
<li>OKR Master Professional Certification</li>
<li>OKR Champion Professional Certification</li>
<li>OKR Certified Professional</li>
<li>Kanban Essentials Professional Certification</li>
</ul>
</td>
</tr>
<tr>
</tr><tr>
<td class="tg-2fdn"><a href="https://www.scrumalliance.org/" target="_blank">Scrum Alliance</a></td>
<td class="tg-2fdn">16</td>
<td class="tg-2fdn">
<ul>
<li>Certified Scrum Master</li>
<li>Advanced Certified Scrum Master</li>
<li>Certified Scrum Professional - Scrum Master</li>
<li>Certified Scrum Product Owner</li>
<li>Advanced Certified Scrum Product Owner</li>
<li>Certified Scrum Professional - Product Owner</li>
<li>Certified Scrum Developer</li>
<li>Advanced Certified Scrum Developer</li>
<li>Certified Scrum Professional - Developer</li>
<li>Certified Team Coach</li>
<li>Certified Enterprise Coach</li>
<li>Certified Scrum Trainer</li>
<li>Certified Agile Leadership Essentials</li>
<li>Certified Agile Leadership for Teams</li>
<li>Certified Agile Leadership for Organizational Leaders</li>
<li>Agile Coaching Skills - Certified Facilitator</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.scrum.org/" target="_blank">Scrum.org</a> </td>
<td class="tg-2fdn">14</td>
<td class="tg-2fdn">
<ul>
<li>Professional Scrum Master I</li>
<li>Professional Scrum Master II</li>
<li>Professional Scrum Master III</li>
<li>Professional Scrum Product Owner I</li>
<li>Professional Scrum Product Owner II</li>
<li>Professional Scrum Product Owner III</li>
<li>Professional Scrum Developer</li>
<li>Scaled Professional Scrum</li>
<li>Professional Scrum with Kanban</li>
<li>Professional Scrum with User Experience</li>
<li>Professional Agile Leadership</li>
<li>Professional Agile Leadership - Evidence Based Management</li>
<li>Professional Facilitation Skills</li>
<li>Professional Backlog Management Skills</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.exin.com/" target="_blank">EXIN</a></td>
<td class="tg-2fdn">14</td>
<td class="tg-2fdn">
<ul>
<li>Agile Scrum Foundation</li>
<li>Agile Scrum Master</li>
<li>Agile Scrum Product Owner</li>
<li>Agile Scrum Product Owner Bridge</li>
<li>Agile Coach</li>
<li>Agile Business Professional</li>
<li>Agile Service Manager</li>
<li>Integrator in Agile Service Projects</li>
<li>Kanban Foundation</li>
<li>DevOps Foundation</li>
<li>DevOps Professional</li>
<li>DevOps Master</li>
<li>DevSecOps Manager</li>
<li>Lean IT Leadership</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.agilecoachesalliance.org" target="_blank">Agile Coaches Alliance</a></td>
<td class="tg-2fdn">14</td>
<td class="tg-2fdn">
<ul>
<li>Accreditation of Progress for Agile Organizations</li>
<li>Accreditation of Progress for Scrum Teams</li>
<li>Accreditation of Practical knowledge for Scrum Masters</li>
<li>Accreditation of Practice for Scrum Masters</li>
<li>Accreditation of Excellence for Scrum Masters</li>
<li>Accreditation of Practical Knowledge for Product Owners</li>
<li>Accreditation of Practice for Product Owners</li>
<li>Accreditation of Excellence for Product Owners</li>
<li>Accreditation of Practice for Agile Leaders</li>
<li>Accreditation of Excellence for Agile Leaders</li>
<li>Accreditation of Practice for Agile Developers</li>
<li>Accreditation of Excellence for Agile Developers</li>
<li>Accreditation of Practice for Agile Advisors</li>
<li>Accreditation of Excellence for Agile Advisors</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.scaledagile.com/" target="_blank">Scaled Agile Framework</a></td>
<td class="tg-2fdn">13</td>
<td class="tg-2fdn">
<ul>
<li>Leading SAFe</li>
<li>Implementing SAFe</li>
<li>SAFe for Teams</li>
<li>SAFe Product Owner/Product Manager</li>
<li>SAFe Scrum Master</li>
<li>Advanced SAFe Scrum Master</li>
<li>SAFe Release Train Engineer</li>
<li>SAFe Lean Portfolio Management</li>
<li>SAFe Agile Product Management</li>
<li>SAFe for DevOps</li>
<li>SAFe for Architects</li>
<li>SAFe for Government</li>
<li>SAFe Agile Software Engineering</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://devopsinstitute.com/" target="_blank">DevOps Institute</a></td>
<td class="tg-2fdn">13</td>
<td class="tg-2fdn">
<ul>
<li>DevOps Foundation</li>
<li>DevOps Engineering Foundation</li>
<li>DevOps Observability Foundation</li>
<li>Site Reliability Engineering Foundation</li>
<li>Site Reliability Engineering Practitioner</li>
<li>DevSecOps Foundation</li>
<li>DevSecOps Practitioner</li>
<li>DevOps Leader</li>
<li>Certified Agile Service Manager</li>
<li>Continuous Testing Foundation</li>
<li>Continuous Testing Practitioner</li>
<li>Value Stream Management Foundation</li>
<li>Value Stream Management Practitioner</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.kanban.university/" target="_blank">Kanban University</a></td>
<td class="tg-2fdn">12</td>
<td class="tg-2fdn">
<ul>
<li>Team Kanban Practitioner</li>
<li>Kanban Management Professional</li>
<li>Enterprise Kanban Management Professional</li>
<li>Scrum Kanban Practitioner</li>
<li>Kanban Product Professional</li>
<li>Kanban Leadership Professional</li>
<li>Kanban Coaching Professional</li>
<li>Accredited Kanban Consultant</li>
<li>Accredited Kanban Trainer</li>
<li>Legal Kanban Practitioner</li>
<li>Customer Experience Professional</li>
<li>Enterprise Services Planning Professional</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.devops-certification.org/" target="_blank">International DevOps Certification Academy</a></td>
<td class="tg-2fdn">12</td>
<td class="tg-2fdn">
<ul>
<li>Certified DevOps Generalist</li>
<li>Certified DevOps Executive</li>
<li>Certified DevOps Project Manager</li>
<li>Certified DevOps Product Owner</li>
<li>Certified DevOps Architect</li>
<li>Certified DevOps Developer</li>
<li>Certified DevOps Operations Engineer</li>
<li>Certified DevOps Quality Assurance Engineer</li>
<li>Certified DevOps Information Security Engineer</li>
<li>Certified DevOps Release Manager</li>
<li>Certified DevOps Trainer</li>
<li>Certified DevOps Coach</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.scrum-institute.org/" target="_blank">Scrum Institute</a></td>
<td class="tg-2fdn">12</td>
<td class="tg-2fdn">
<ul>
<li>Scrum Team Member Accredited Certification</li>
<li>Scrum Developer Accredited Certification</li>
<li>Scrum Master Accredited Certification</li>
<li>Scrum Product Owner Accredited Certification</li>
<li>Scaled Scrum Expert Accredited Certification</li>
<li>Agile Scrum Leadership (Executive) Accredited Certification</li>
<li>Scrum Trainer Accredited Certification</li>
<li>Agile Coach Accredited Certification</li>
<li>Certified Kanban Expert Certification</li>
<li>Certified Kanban Project Manager Certification</li>
<li>Certified Professional in Design Thinking Certification</li>
<li>Certified Professional in OKR Certification</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.scrumstudy.com/" target="_blank">ScrumStudy</a></td>
<td class="tg-2fdn">10</td>
<td class="tg-2fdn">
<ul>
<li>Scrum Fundamentals Certified</li>
<li>Scrum Developer Certified</li>
<li>Scrum Master Certified</li>
<li>Scaled Scrum Master Certified</li>
<li>ScrumStudy Agile Master Certified</li>
<li>Scrum Product Owner Certified</li>
<li>Scaled Scrum Product Owner Certified</li>
<li>Expert Scrum Master Certified</li>
<li>Scrumstudy Certified Trainer</li>
<li>Scrumstudy Certified Agile Coach</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.ihk.de/" target="_blank"><span class="copyright">Industrie- und Handelskammern</span></a><sup>1</sup></td>
<td class="tg-2fdn">9</td>
<td class="tg-2fdn">
<ul>
<li>Agiler Projektmanager IHK</li>
<li>Agiles Projektmanagement IHK</li>
<li>Agiler Personalentwickler IHK</li>
<li>Agiler Business Coach IHK</li>
<li>Agiler Team Coach IHK</li>
<li>Agiler Change Manager IHK</li>
<li>Agile Führungskraft IHK</li>
<li>Fachkraft für agile Führung IHK </li>
<li>Agiler Mindsetter IHK</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="http://www.europeanscrum.org/" target="_blank">EuropeanScrum</a></td>
<td class="tg-2fdn">9</td>
<td class="tg-2fdn">
<ul>
<li>Certificate in Scrum Foundations</li>
<li>Certificate in Scrum Master</li>
<li>Certificate in Product Owner</li>
<li>Certificate in Agile HR</li>
<li>Certificate in Agile Coach</li>
<li>Certificate in Kanban</li>
<li>Certificate in Design Thinking</li>
<li>Certificate in Visual Thinking</li>
<li>Certificate in Lean Foundations</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.scruminc.com/" target="_blank">Scrum Inc</a></td>
<td class="tg-2fdn">8</td>
<td class="tg-2fdn">
<ul>
<li>Registered Scrum Team Member</li>
<li>Registered Scrum@Scale Practitioner</li>
<li>Registered Scrum Master</li>
<li>Registered Scrum Master@Scale</li>
<li>Registered Scrum Product Owner</li>
<li>Registered Scrum Product Owner@Scale</li>
<li>Registered Agile Leader@Scale</li>
<li>Registered Agile Coach</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="http://www.flightlevelsacademy.com/" target="_blank">Flight Levels Academy</a></td>
<td class="tg-2fdn">8</td>
<td class="tg-2fdn">
<ul>
<li>Introduction to Flight Levels</li>
<li>Flight Level 2 Design</li>
<li>Flight Level 3 Design</li>
<li>Flight Levels Systems Architecture</li>
<li>Flight Levels Change Leadership</li>
<li>Flight Levels Coach</li>
<li>Flight Levels Data Driven Improvement</li>
<li>Flight Levels Dependency Management</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.scrumagileinstitute.com/" target="_blank">Scrum Agile Institute</a></td>
<td class="tg-2fdn">8</td>
<td class="tg-2fdn">
<ul>
<li>Scrum Master Certified</li>
<li>Scrum Master Instructor</li>
<li>Scrum Product Owner Certified</li>
<li>Product Owner Instructor</li>
<li>Scrum Developer Certified</li>
<li>Scrum Developer Instructor</li>
<li>Agile Scaled Certified</li>
<li>Agile Scaled Instructor</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://agileacademy.training" target="_blank">Agile Academy</a></td>
<td class="tg-2fdn">8</td>
<td class="tg-2fdn">
<ul>
<li>Certified Agile Coach</li>
<li>Certified Agile Coach Advanced</li>
<li>Certified Agile OKR Coach</li>
<li>Certified Agile Facilitator</li>
<li>Certified Agile Kanban Coach</li>
<li>Certified Agile Leadership Coach</li>
<li>Certified Agile Trainer</li>
<li>Certified Design Thinking Coach</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.devopsagileskills.org/" target="_blank"> DevOps Agile Skills Association</a></td>
<td class="tg-2fdn">7</td>
<td class="tg-2fdn">
<ul>
<li>DevOps Fundamentals</li>
<li>DevOps Professional Enable and Scale</li>
<li>DevOps Professional Specify and Verify</li>
<li>DevOps Professional Create and Deliver</li>
<li>DevOps Product Owner</li>
<li>DevOps Leader</li>
<li>DevOps Coach</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://apmg-international.com/" target="_blank">APM Group International</a></td>
<td class="tg-2fdn">7</td>
<td class="tg-2fdn">
<ul>
<li>Agile Digital Services</li>
<li>Agile Programme Management</li>
<li>Agile Project Management</li>
<li>Agile Agile Business Analysis</li>
<li>Agile Project Management for Scrum</li>
<li>Agile Change Agent</li>
<li>Agile Scrum Certification</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://prokanban.org/" target="_blank">ProKanban</a></td>
<td class="tg-2fdn">6</td>
<td class="tg-2fdn">
<ul>
<li>Professional Kanban Level I</li>
<li>Professional Kanban Level II</li>
<li>Professional Flow Metrics Fundamentials</li>
<li>Professional Applied Metrics</li>
<li>Professional Flow Metrics for Scrum</li>
<li>Scaling with Portfolio Kanban</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://less.works/" target="_blank">Large Scale Scrum</a><sup>2</sup></td>
<td class="tg-2fdn">5</td>
<td class="tg-2fdn">
<ul>
<li>Certified LeSS Basics</li>
<li>Certified LeSS Practitioner</li>
<li>Certified LeSS for Executives</li>
<li>Certified LeSS Trainer</li>
<li>LeSS-Friendly Scrum Trainer</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://openspaceagility.com/" target="_blank"><span class="copyright">OpenSpace Agility Framework</span></a></td>
<td class="tg-2fdn">5</td>
<td class="tg-2fdn">
<ul>
<li>Open Space Agility Level 1</li>
<li>Open Space Agility Level 2</li>
<li>OpenSpace Technology Level 1</li>
<li>OpenSpace Technology Level 2</li>
<li>Open Space Agility Certified Trainer</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.pmi.org/" target="_blank">Project Management Institute</a></td>
<td class="tg-2fdn">5</td>
<td class="tg-2fdn">
<ul>
<li>PMI Agile Certified Practitioner</li>
<li>Disciplined Agile Scrum Master</li>
<li>Disciplined Agile Senior Scrum Master</li>
<li>Disciplined Agile Value Stream Consultant</li>
<li>Disciplined Agile Coach</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://leanchange.org" target="_blank">Lean Change</a></td>
<td class="tg-2fdn">4</td>
<td class="tg-2fdn">
<ul>
<li>Lean Change Foundations</li>
<li>Change Agilist</li>
<li>Coaching Agile Transitions</li>
<li>Enterprise Agile Coaching</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.agilecoachalliance.org/" target="_blank">Agile Coach Alliance</a></td>
<td class="tg-2fdn">4</td>
<td class="tg-2fdn">
<ul>
<li>Certified Agile Coach</li>
<li>Certified Agile HR</li>
<li>Certified Agile Trainer</li>
<li>Certified Agile Coach Trainer</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.agilemarketingacademy.com/" target="_blank">Agile Marketing Academy</a></td>
<td class="tg-2fdn">4</td>
<td class="tg-2fdn">
<ul>
<li>Certified Agile Marketing Specialist</li>
<li>Certified Agile Marketing Practitioner</li>
<li>Certified Agile Marketing Coach</li>
<li>Certified Agile Marketing Trainer</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://agilepeopleopsframework.com" target="_blank">Agile PeopleOps Framework </a><br /></td>
<td class="tg-2fdn">4</td>
<td class="tg-2fdn">
<ul>
<li>Agile PeopleOps Agility</li>
<li>Agile PeopleOps Business Partner</li>
<li>Agile PeopleOps Practitioner</li>
<li>Agile PeopleOps Coaching</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://agilityhealthradar.com/" target="_blank">AgilityHealth</a></td>
<td class="tg-2fdn">4</td>
<td class="tg-2fdn">
<ul>
<li>Certified AgilityHealth Facilitator</li>
<li>Continuous Improvement Champion</li>
<li>Agility OKR Champion</li>
<li>Enterprise Business Agility Strategist</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.ibqmi.org/" target="_blank">International Business and Quality Management Institute</a></td>
<td class="tg-2fdn">4</td>
<td class="tg-2fdn">
<ul>
<li>Certified Kanban Coach</li>
<li>Approved Kanban Professional</li>
<li>Certified Scrumban Practitioner</li>
<li>Certified DevOps Manager</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://okrinstitute.org/" target="_blank">OKR Institute</a></td>
<td class="tg-2fdn">4</td>
<td class="tg-2fdn">
<ul>
<li>OKR Foundation</li>
<li>OKR Practitioner</li>
<li>OKR Professional</li>
<li>OKR Leader</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://eduscrum.org/" target="_blank">EduScrum</a></td>
<td class="tg-2fdn">4</td>
<td class="tg-2fdn">
<ul>
<li>EduScrum Level 1</li>
<li>EduScrum Level 2</li>
<li>EduScrum Level 3</li>
<li>EduScrum Train the Trainer</li>
</ul>
</td>
</tr>
<tr><td class="tg-2fdn"><a href="https://www.tuev.de" target="_blank">TÜV<sup>3</sup></a></td>
<td class="tg-2fdn">4</td>
<td class="tg-2fdn">
<ul>
<li>Agiles Projektmanagement</li>
<li>Scrum Foundation Zertifikat</li>
<li>Scrum Master Zertifikat</li>
<li>Product Owner Zertifikat</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.axelos.com/" target="_blank">Axelos</a></td>
<td class="tg-2fdn">3</td>
<td class="tg-2fdn">
<ul>
<li>Prince2 Agile Foundation</li>
<li>Prince2 Agile Practitioner</li>
<li>AgileShift Certification</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://allianceforqualification.com/" target="_blank">Alliance for Qualification</a></td>
<td class="tg-2fdn">3</td>
<td class="tg-2fdn">
<ul>
<li>Design Thinking Foundation
</li><li>Practitioner in Agile Quality</li>
<li>Certified Agile Business Analysis</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.iapm.net/" target="_blank">International Association of Project Managers</a></td>
<td class="tg-2fdn">3</td>
<td class="tg-2fdn">
<ul>
<li>Certified Junior Agile Project Manager IAPM</li>
<li>Certified Agile Project Manager IAPM</li>
<li>Certified Senior Agile Project Manager IAPM</li>
</ul>
</td>
</tr>
<tr><td class="tg-2fdn"><a href="https://www.ineko-cologne.com/" target="_blank">Ineko Institut (Universität Köln)</a></td>
<td class="tg-2fdn">3</td>
<td class="tg-2fdn">
<ul>
<li>Basic Agile Master</li>
<li>Experienced Agile Master</li>
<li>Systemic Agile Master & Coach</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.istqb.org/" target="_blank">International Software Testing Qualifications Board</a></td>
<td class="tg-2fdn">2</td>
<td class="tg-2fdn">
<ul>
<li>Foundation Level Agile Tester</li>
<li>Advanced Level Agile Technical Tester</li>
<li>Agile Test Leadership at Scale</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://isqi.org/" target="_blank">International Software Quality Institute</a></td>
<td class="tg-2fdn">3</td>
<td class="tg-2fdn">
<ul>
<li>Certified Agile Essential</li>
<li>Certified Agile OKR Master</li>
<li>Scrum Master Pro</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://okrconsortium.com/" target="_blank">OKR Consortium</a></td>
<td class="tg-2fdn">3</td>
<td class="tg-2fdn">
<ul>
<li>Certified OKR Practitioner</li>
<li>Certified OKR Coach</li>
<li>Certified OKR Executive</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.bcs.org/" target="_blank">British Computer Society - The Chartered Institute for IT</a></td>
<td class="tg-2fdn">2</td>
<td class="tg-2fdn">
<ul>
<li>Foundation Certificate in Agile</li>
<li>Foundation Certificate in DevOps</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.ireb.org/" target="_blank">International Requirements Engineering Board</a></td>
<td class="tg-2fdn">2</td>
<td class="tg-2fdn">
<ul>
<li>Re@Agile</li>
<li>Re@Agile Advanced Level</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://kpiinstitute.org/" target="_blank">KPI Institute</a></td>
<td class="tg-2fdn">2</td>
<td class="tg-2fdn">
<ul>
<li>Certified Agile Strategy Execution</li>
<li>Certified OKR Professional</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.itsmacademy.com/" target="_blank">IT Service Management Academy</a></td>
<td class="tg-2fdn">1</td>
<td class="tg-2fdn">
<ul>
<li>Certified Agile Service Manager</li>
</ul>
</td>
</tr>
<tr>
<td class="tg-2fdn"><a href="https://www.dekra-akademie.de/weiterbildung/agiles-projektmanagement" target="_blank">DEKRA</a></td>
<td class="tg-2fdn">1</td>
<td class="tg-2fdn">
<ul>
<li>Agiles Projektmanagement mit Scrum</li>
</ul>
</td>
</tr>
</tbody></table>
<span style="font-size: x-small;"><sup>1</sup></span><span style="font-size: x-small;">Zertifizierungslehrgänge verschiedener Kammern</span><br />
<span style="font-size: x-small;"><sup>2</sup>Der </span><span style="font-size: x-small;">LeSS-Friendly Scrum Trainer ist eine Erweiterung des Certified Scrum Trainer der Scrum Alliance</span><br />
<span style="font-size: x-small;"><sup>3</sup></span><span style="font-size: x-small;">Zertifizierungslehrgänge verschiedener TÜV-Gesellschaften</span>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-53038223630638327272024-01-15T09:30:00.039+01:002024-01-15T09:30:00.148+01:00Dunning, Kruger & KI<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNc9dMf05o46JGiSOkp0PYaG7o8-s2Fwyv2dX13HzQ7EimumQoso6XWbYz7ryDJqKwiDxecmw0wUypRAWgnxdoZHX_Zxq144aAVgtJQbifqq5R7Ri_p3Ow6BVdrszMfqArhhS5NB-54SBqZsJLwja-Bbzi1m54HyjgK3A4iOWi1Ch8cBIYMyBs_dg4VBkO/s1024/a_robot_working_on_a_flowchart.jpg" style="display: block; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="640" data-original-width="1024" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNc9dMf05o46JGiSOkp0PYaG7o8-s2Fwyv2dX13HzQ7EimumQoso6XWbYz7ryDJqKwiDxecmw0wUypRAWgnxdoZHX_Zxq144aAVgtJQbifqq5R7Ri_p3Ow6BVdrszMfqArhhS5NB-54SBqZsJLwja-Bbzi1m54HyjgK3A4iOWi1Ch8cBIYMyBs_dg4VBkO/w640-h400/a_robot_working_on_a_flowchart.jpg" width="640" /></a></div>
<p>Dass die allgemeine Verfügbarkeit von KI-Anwendungen (KI = künstliche Intelligenz) die Arbeitswelt in kurzer Zeit stark verändert hat, ist ein Allgemeinplatz, welche Veränderungen das sind, ist im Einzelfall aber doch immer wieder überraschend. So gehört anscheinend zu ihnen, dass die Nutzung von KI zu einem verstärkten Auftreten des <a href="https://www.linkedin.com/events/105-scrumtischbonn7150906951902658560/" target="_blank">Dunning-Kruger Effektes</a> führen kann, also zu einer unrealistisch guten Selbsteinschätzung, gerade dann wenn eigentlich das Gegenteil der Fall ist.<br /></p>
<p><br /></p>
<p>Nachlesen kann man das aktuell in einer <a href="https://snyk.io/de/reports/ai-code-security/" target="_blank">Studie des IT-Sicherheits-Providers Snyk</a>, die auf Interviews mit 500 Entwicklern beruht, schon etwas älter (von 2022) ist eine <a href="https://arxiv.org/abs/2211.03622" target="_blank">Meta-Studie der Stanford University</a>, die die Forschungsergebnisse mehrerer amerikanischer und kanadischer Wissenschaftler zusammenfasst. Ohne David Dunning, Justin Kruger oder ihr Paper <a href="https://www.researchgate.net/publication/12688660_Unskilled_and_Unaware_of_It_How_Difficulties_in_Recognizing_One%27s_Own_Incompetence_Lead_to_Inflated_Self-Assessments" target="_blank">Unskilled and unaware of it</a> beim Namen zu nennen, beschreiben sie genau das, was den nach ihnen benannten Effekt ausmacht.<br /></p>
<p><br /></p>
<p>Zum Hintergrund: es gibt systemische Gründe, wegen denen der von KI-Tools generierte Code oft schlecht ist. Anders als von Laien angenommen lernen diese Programme nicht selbst, sondern werden von Menschen trainiert, und zwar aus Kostengründen <a href="https://time.com/6247678/openai-chatgpt-kenya-workers/" target="_blank">von Billigkräften aus Afrika oder Asien</a>. Bei einfachen Wissensfragen oder Bildgenerierungen funktioniert das auch gut, beim Überprüfen von Quellcode kommen Menschen dieses Gehalts- (und damit Bildungs-)Niveaus aber schnell an Grenzen.<br /></p>
<p><br /></p>
<p>Die Grundlage dieser Trainings ist (vereinfacht gesagt) aller im Internet stehender Code, der natürlich in weiten Teilen schon älter ist. Der auf dieser Basis generierte neue Code ist daher nicht in dem Sinn schlecht, dass er nicht funktioniert (das würde dann doch auffallen), er ist es in dem Sinn, dass er an veralteten Architektur- und Sicherheitsstandards ausgerichtet ist und die so erzeugten Programme aus diesem Grund schwerer verständlich, aufwändiger in der Wartung oder einfacher zu hacken sind.<br /></p>
<p><br /></p>
<p>Statt sich dessen bewusst zu sein, herrschte bei den an den Untersuchungen teilnehmenden Entwicklern aber mehrheitlich die genau gegenteilige Meinung vor: sie waren davon überzeugt, dass der Code, den sie sich von ihrer KI (z.B. von Github Copilot oder Facebook InCoder) hatten generieren lassen, modern, gut lesbar und sicher wäre. Und genau das, die unrealistisch hohe Meinung über die Qualität eher dürftiger eigener Arbeitsergebnisse, ist der Dunning Kruger Effekt.</p>
<p><br /></p>
<p>Die genauen Gründe, aus denen dieser Effekt in genau diesem Kontext auftritt, sind in den genannten Studien nicht erforscht (und es ist auch fraglich, ob ihre Identifizierung so einfach möglich wäre), einen vermutlich nicht unwichtigen Faktor hat aber <a href="https://www.infoq.com/podcasts/culture-trends-2023/" target="_blank">Rebecca Parsons, der CTO von Thoughtworks, beschrieben</a>: die Antworten der Chatbots sind immer so formuliert, dass sie den Eindruck zweifelloser Richtigkeit erwecken. Das kann dazu führen, dass diese dann auch vom Anwender angenommen wird.<br /></p>
<p><br /></p>
<p>Die Lehre die man daraus ziehen kann ist, dass gerade KI-generierter Code mit grosser Vorsicht behandelt und möglichst sorgfältig reviewt werden sollte, bevor er irgendwo integriert und deployed wird. Das führt zwar dazu, dass die Menge der Arbeit, die man an eine künstliche Intelligenz delegieren kann gefühlt weniger wird, dafür ist das Ergebnis aber auch besser und sicherer. Und auch das gehört zu Dunning Kruger dazu - wenn man gemerkt hat, dass man betroffen ist, geht der Effekt zurück.<br /></p>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-6555032795247551712024-01-11T09:30:00.005+01:002024-01-11T09:30:00.127+01:00Gall's Law<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPYwFG8lZqYrkt42gQvBY_xTm6gapOiedZ8nPeyRrAj-D1kk0OjpPnYpXjLeo8sdLWEQCkmbLJMcJxxp3Q4ySFYEYcW5o8VicxzUWfjCTKcPWP7QKhV4PF-yYVwVuNpiPh2Y2YtZh8f30_2dXXKVJEPMn-taDjV2RyV4rmzREYvcsRYz2R8r9fpy909HZQ/s1024/legal_texts.jpg" style="display: block; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="640" data-original-width="1024" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPYwFG8lZqYrkt42gQvBY_xTm6gapOiedZ8nPeyRrAj-D1kk0OjpPnYpXjLeo8sdLWEQCkmbLJMcJxxp3Q4ySFYEYcW5o8VicxzUWfjCTKcPWP7QKhV4PF-yYVwVuNpiPh2Y2YtZh8f30_2dXXKVJEPMn-taDjV2RyV4rmzREYvcsRYz2R8r9fpy909HZQ/w640-h400/legal_texts.jpg" width="640" /></a></div>
<p>Herzlich willkommen, liebe Leser, das heutige Thema ist ein weiteres "Gesetz", oder besser gesagt eine weitere pointierte Betrachtung über regelmässig zu beobachtende Phänomene der Organisations- und Softwareentwicklung, diesesmal vom amerikanischen Arzt, Systemtheoretiker und Historiker <a href="https://en.wikipedia.org/wiki/John_Gall_(author)" target="_blank">John Gall</a>: das nach ihm benannte <a href="https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law" target="_blank">"Gall's Law"</a>, im deutschen manchmal unter dem Titel "Gall'sches Gesetz" anzutreffen. Es lautet folgendermassen:<br /></p>
<p><br /></p>
<blockquote><div>A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never
works and cannot be patched up to make it work. You have to start over with a working simple system.<br />
</div><div style="text-align: right;">(John Gall: Systemantics - How Systems Really Work and How They Fail)</div></blockquote>
<p><br /></p>
<p>Ins Deutsche übersetzt: Ein komplexes System, das funktioniert, hat sich in jedem Fall aus einem einfachen
System entwickelt, das funktioniert hat. Ein komplexes System, das von
Grund auf neu entwickelt wurde, funktioniert nie und kann nicht dazu gebracht werden zu funktionieren. Man muss mit einem funktionierenden,
einfachen System neu beginnen. Eine starke Aussage, aber ist an ihr auch etwas dran? Ist es wirklich so, dass man komplexe Systeme nicht neu entwickeln kann?<br /></p>
<p><br /></p>
<p>Die Antwort darauf ist ausnahmsweise nicht "kommt drauf an", sondern "kann man nicht genau sagen", und zwar aus einem einfachen Grund: weder für ein komplexes System noch für ein funktionierendes System gibt es eine allgemein anerkannte Definition, die eine einwandfreie Zuordnung einzelner Fälle ermöglichen würde. Um allgemein anwendbar sein müssen derartige Definitionen abstrakt bleiben, wodurch der Einzelfall niemals eindeutig zuzuordnen ist.<br /></p>
<p><br /></p>
<p>Was hingegen reichlich vorhanden ist, ist <a href="https://www.lean-agility.de/2020/02/anekdotische-evidenz.html" target="_blank">anekdotische Evidenz</a>, und die geht klar in Galls Richtung. Im Software-Bereich wäre z.B. die seit Jahren vor sich hin scheiternde Entwicklung <a href="https://www.merkur.de/wirtschaft/vw-cariad-volkswagen-wolfsburg-software-entwicklung-porsche-audi-infotainment-probleme-zr-92659117.html" target="_blank">des "Auto-Betriebssystems" von VW</a> zu nennen, aber auch viele andere von <a href="https://t3n.de/news/500-millionen-euro-projekt-scheitert-lidl-blaest-sap-software-ab-1095673/" target="_blank">Lidl</a> bis <a href="https://www.spiegel.de/wirtschaft/unternehmen/deutsche-bank-it-probleme-bei-der-postbank-dauern-laenger-als-geplant-a-28c6617e-e171-4014-ba18-f63e04dc09fa" target="_blank">Postbank</a>, im Bereich der Organisationsentwicklung die unzähligen Konzern-Reorganisationen, von denen <a href="https://www.forbes.com/sites/grantfreeland/2018/11/05/oh-no-not-another-reorganization-do-we-really-need-one/?sh=59d015102887" target="_blank">laut einer Studie in über 1000 Unternehmen</a> über 50 % ihr Ziel verfehlen (die tatsächliche Zahl dürfte nochmal höher sein).<br /></p>
<p><br /></p>
<p>Der Gund dafür dürfte im Wesen der <a href="https://de.wikipedia.org/wiki/Komplexit%C3%A4t" target="_blank">Komplexität</a> liegen, die sich dadurch auszeichnet, dass in den von ihr betroffenen Systemen so viele Teilbereiche auf so unterschiedliche und unübersichtliche Art miteinander verbunden sind, dass ihre Interaktion (bzw. deren Ergebnisse) unvorhersehbar ist. Und genau hier liegt das Problem: Unvorhersehbarkeit bedeutet in diesem Zusammenhang nämlich auch, dass die Abläufe und Koordinationsmechanismen nicht im Voraus planbar sind.<br /></p>
<p><br /></p>
<p>Was dagegen möglich ist, ist die emergente Entstehung eines komplexen Systems. Mit anderen Worten: beginnt man mit einem noch einfachen, stabilen System kann man diesem in kleinen Schritten komplexitätsfördernde Faktoren (Größe, Kleinteiligkeit, Vielfältigkeit, Vernetzung, Dynamik, etc.) hinzufügen, deren Auswirkungen beobachten, sie ggf. kompensieren und nach dieser Stabilisierung den nächsten kleinen Schritt gehen. So wächst das komplexe System (halbwegs) kontrolliert heran.<br /></p>
<p><br /></p>
<p>Das ist der Hintergrund von Gall's Law. Eigentlich verständlich, es bleibt nur eine Frage zu klären: warum dieser Absolutheitsanspruch mit den kategorischen Aussagen, dass man in jedem Fall einfach beginnen mus und dass ein komplexer Gesamtentwurf nie funktionieren kann? Wäre Differenzierung nicht besser? Man kann nur raten, aber zwei Gründe liegen nah - zum einen verkauft sich Prägnanz gut und zum anderen wäre eine differenzierte Aussage eine zu vermutlich eine zu schwache Warnung.<br /></p>
<p><br /></p>
<p>Würde Gall's Law z.B. lauten, dass über 50 % aller Versuche komplexe Systeme zu entwerfen ihre Ziele nicht vollständig erreichen, wäre das zwar akkurater, es würde aber auch weniger Menschen davon abhalten es doch zu versuchen. Dann lieber die polemische, dafür aber deutliche Warnung. Wer auf die nicht hört, kann zumindest nachher nicht mehr sagen, es habe von nichts gewusst.<br /></p>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-75650272785292973312024-01-08T09:30:00.001+01:002024-01-08T09:30:00.153+01:00Bullshit Jobs and Fake Agile<p>Dieser Vortrag von Nigel Thurlow ist eine Provokation, allerdings eine mit einem ernsthaften Hintergrund. Anhand der Definitionen <a href="https://en.wikipedia.org/wiki/Bullshit_Jobs" target="_blank">aus dem Buch Bullshit Jobs</a> bezeichnet er Product Owner, Scrum Master und Agile Coaches als genau solche, da sie oft nur Schein- oder Alibi-Tätigkeiten ausüben, weil die Verbesserungen, die sie eigentlich bewirken sollen, durch politische oder systemische Faktoren verhindert werden. Man muss es leider zugestehen - das was er beschreibt kommt in der Realität vor.<br /></p>
<p><br /></p>
<iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/njI9Bxyr-Hw?si=7mvqFB4iYOuNROyl&start=169" title="YouTube video player" width="560"></iframe>
<p><br /></p>
<p>Umgekehrt kann man seine Ausführungen aber auch als Anleitung dafür nehmen, wie es besser geht. Wenn wirkliche Agilität das Ziel ist, kann man Output-Fixierung, fehlende Systemsicht, falsche Anreizgebung, komplizierte Aufbauorganisationen und die weiteren von ihm genannten Hindernisse abbauen. Und wenn Product Owner, Scrum Master und Agile Coaches daran arbeiten dürfen, sind es auch keine Bullshit-Jobs mehr.<br /></p>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-26145652115644799702024-01-04T09:30:00.014+01:002024-01-04T09:30:00.131+01:00Die VUCA-Verkennung<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi8ucOz3FsVJU8mg9s4SjzZzrLEDaf3YaYqhptAizxwUb-VcrozODKaucOkFCpUrUYYXDD8LBQM8hC5nd8vGa91D8L-AIUiRq5fhkVOZL-ggyCc6GX85qNDns74v3C6kUMnmgmlbzKphMLh-iOnfmsgvIBlV8RLE-oqB7thqKOL8rdrLteVCq15U3aRQ9HG/s1024/VUCA.jpg" style="display: block; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="640" data-original-width="1024" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi8ucOz3FsVJU8mg9s4SjzZzrLEDaf3YaYqhptAizxwUb-VcrozODKaucOkFCpUrUYYXDD8LBQM8hC5nd8vGa91D8L-AIUiRq5fhkVOZL-ggyCc6GX85qNDns74v3C6kUMnmgmlbzKphMLh-iOnfmsgvIBlV8RLE-oqB7thqKOL8rdrLteVCq15U3aRQ9HG/w640-h400/VUCA.jpg" width="640" /></a></div>
<p>Wenn es einen Begriff gibt, der von fast jedem Agile Coach oder Scrum Master regelmässig benutzt wird, dann ist es VUCA (volatility, uncertainty, complexity, ambiguity), bzw. dessen deutsche Übersetzung VUKA (Volatilität, Unsicherheit, Komplexität, Ambiguität). Meistens verwendet um zu zeigen, aufgrund welcher Faktoren Agilität nötig ist, verbirgt sich hinter ihm oft eine interessante Wahrnehmungs-Schere: die Selbsteinschätzungen der Betroffenheit durch VUCA gehen z.T. weit auseinander.<br /></p>
<p><br /></p>
<p>Aus einer abstrakten Beobachterposition heraus ist die Sache klar: <a href="https://www.lean-agility.de/2019/11/gesetzliche-regulierung.html" target="_blank">sich ändernde Rahmenbedingungen</a>, <a href="https://www.lean-agility.de/2017/08/feature-wettrennen.html" target="_blank">Marktdynamiken</a> und unerwartete Ergebnisse von <a href="https://www.lean-agility.de/2020/12/minimum-viable-products-mvps.html" target="_blank">Hypothesen-Validierungen</a> setzen praktisch jedem Entwicklungsteam permanent zu, so dass regelmässiges Innehalten, Abgleichen des Ist-Standes mit dem Ziel und ein Abgleichen des Ziels mit der möglicherweise veränderten Realität zwingend notwendig ist, wenn man nicht am Bedarf vorbeiarbeiten und so die eigene Firma gefährden will.<br /></p>
<p><br /></p>
<p>Umgekehrt gibt es aber interessanterweise aus vielen Teams und Management-Runden die genau entgegengesetzte Wahrnehmung. Die Existenz von Volatilität, Unsicherheit, Komplexität und Ambiguität im eigenen Umfeld wird hinterfragt oder sogar negiert, oft mit dem Hinweis, dass die Umgebungsfaktoren seit Jahren oder sogar Jahrzehnten unverändert und stabil wären. Oft treffen diese unterschiedlichen Einschätzungen (Vuca und Nicht-Vuca) sogar im selben Kontext auf - wie kann das sein?<br /></p>
<p><br /></p>
<p>Um den weniger wahrscheinlichen Fall zuerst zu betrachten: es kann tatsächlich vorkommen, dass es im Umfeld von Entwicklungsteams über längere Zeiträume zu keinen unerwarteten Entwicklungen kommt. Ein Fall der mir einmal untergekommen ist war z.B. ein Intranet, das nur mit einem selbstentwickelten Browser aufrufbar war. Es wurde zwar weiterentwickelt, war aber von den Überraschungen und Neuerungen der "Aussenwelt" komplett abgekoppelt. Wie gesagt, möglich aber selten.<sup>1</sup><br /></p>
<p><br /></p>
<p>Wesentlich wahrscheinlicher ist eine andere Erklärung: die Existenz der VUCA-Dynamiken wird nicht erkannt oder (ggf. unbewusst) ignoriert. Wer schon einmal in grösseren Organisationen unterwegs war, wird mit etwas Nachdenken sicher auf einige derartige Fälle kommen, die er selbst miterlebt hat. Wichtig für Ihr Verständnis ist dabei, dass diese "Betriebsblindheit" in den meisten Fällen nicht aus individuellen Schwächen entsteht, sondern systemische Gründe hat. <br /></p>
<p><br /></p>
<p>Einer davon kann ein Organisationsdesign sein, das die Entwicklungsteams durch ein zwischengelagertes Anforderungs- oder Produktmanagement weitgehend von Kunden, Anwendern und externen Faktoren abschirmt. Die äusseren Dynamiken finden in solchen Fällen zwar statt, die Teams sind sich ihrer aber nicht bewusst. Die Konsequenz ist ein irgendwann stattfindendes unschönes Erwachen, z.B. dadurch, dass man im Jahr 2020 herausfindet, dass <a href="https://en.wikipedia.org/wiki/COBOL#Isolation_from_the_computer_science_community" target="_blank">COBOL</a> nicht mehr zeitgemäss ist.<sup>2</sup><br /></p>
<p><br /></p>
<p>Ein zweiter Fall wäre der, den man despektierlich als "kollektive Betriebsblindheit" bezeichnen könnte. Er liegt vor, wenn auf allen Hierarchie-Ebenen und in allen Organisationseinheiten die bestehenden Veränderungsdynamiken nicht erkannt oder als zu unwichtig eingeschätzt werden. Beispiele dafür wären die Mobiltelefon-Sparten von Siemens und Nokia, die das Potential der Smartphones nicht erkannt haben. <a href="https://www.capital.de/wirtschaft-politik/western-von-gestern-der-untergang-der-siemens-handys" target="_blank">Ihr Schicksal</a> zeigt auch auf, welche Folgen solche Verkennungen haben können.<br /></p>
<p><br /></p>
<p>Ebenfalls anzutreffen ist der unschöne Fall, dass Monopolstellungen ausgenutzt werden, um Anwenderwünsche und technische Neuerungen bewusst zu ignorieren. Das wird z.B. einem grossen ERP-Entwickler immer wieder unterstellt, die meisten derartigen Fälle finden aber <a href="https://www.lean-agility.de/2020/11/nutzerzentrierung.html" target="_blank">im Rahmen interner Anwendungsentwicklungen</a> statt, vor allem dort, wo Konzerne ihre eigene Individualsoftware herstellen. Die Konsequenz daraus ist meistens eine zurückgehende Mitarbeiter-Loyalität, ggf. Kündigungen.<sup>3</sup><br /></p>
<p><br /></p>
<p>Welche Variante es auch ist, mit den zu Beginn genannten wenigen Ausnahmen handelt es sich bei fast allen Fällen, in denen Produktentwicklungs-Einheiten glauben, nicht von den VUCA-Faktoren betroffen zu sein, um Verkennungen der Realität, die sich früher oder später rächen werden. Zumindest in einem techniknahen Umfeld sollte man sich daher besser mit ihnen beschäftigen, und zwar auch und gerade dann wenn man das Gefühl hat, ihnen gar nicht ausgesetzt zu sein.</p><p><br /></p>
<p><br /></p>
<span style="font-size: xx-small;"><sup>1</sup>Und ob eine interne Broweser-Entwicklung wirklich ein sinnvoller Ressourcen-Einsatz ist, wäre auch noch hinterfragbar<br />
<sup>2</sup>Diesen Moment der Erkenntnis habe ich bei einigen Teams eines Kunden miterleben dürfen<br />
<sup>3</sup>Auch hier eine Erlebnis aus der Praxis: in einem Townhall Meeting eines Kunden fiel einmal der Satz <i>"Wem's nicht passt, der kann ja gehen." Und die Leute gingen.<br /></i></span>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-75593284445033471752023-12-31T10:00:00.007+01:002023-12-31T10:00:00.139+01:00Kommentierte Links (CIX)<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBoBRmlz1efocOAdGT0kTPFJ7p1-p312jqD4pgLuqazXz25jySPUEr7D8em2LCLMBYBjcMlSXPXK2vksePu7roJY4OUC_ZzEOCPS9mKQ1IC2McWQONVaiMJ0RmQ15KtrkbORpnoUi0r-fmBveWJkVdu47aooY4In8kyS6CiVlP7os3TGEz1pzykUGZnw/s1000/Links.jpg" style="display: block; margin-left: auto; margin-right: auto; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="666" data-original-width="1000" height="426" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBoBRmlz1efocOAdGT0kTPFJ7p1-p312jqD4pgLuqazXz25jySPUEr7D8em2LCLMBYBjcMlSXPXK2vksePu7roJY4OUC_ZzEOCPS9mKQ1IC2McWQONVaiMJ0RmQ15KtrkbORpnoUi0r-fmBveWJkVdu47aooY4In8kyS6CiVlP7os3TGEz1pzykUGZnw/w640-h426/Links.jpg" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Grafik: <a href="https://pixabay.com/de/illustrations/internet-social-media-netzwerk-blog-4463031/" target="_blank">Pixabay / Geralt</a> - <a href="https://pixabay.com/de/service/license/" target="_blank">Lizenz</a></td></tr></tbody></table>
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" aber trotzdem lesenswerten Texte aus dem letzten Jahr.<br />
<br />
<h3><a href="https://spavel.medium.com/design-is-the-art-of-being-wrong-safely-7575b0c395c2" target="_blank">Pavel Samsonov: Design is the art of being wrong safely</a></h3>
Pavel Samsonov zeigt hier einen interessanten Blickwinkel auf die Ergebnisse früher Design Thinking-, Design Sprint und Lean Startup-Phasen auf. Das was in ihnen erzeugt wird, ist fast immer ein falsches Ergebnis, und zwar falsch in dem Sinn, dass es auf Hypothesen basierende Prototypen oder <a href="https://www.lean-agility.de/2020/12/minimum-viable-products-mvps.html" target="_blank">MVPs</a> sind, die per Definition noch gar nicht richtig sein können, da der Product-Discovery-Prozess mit ihnen erst beginnt. Um das nicht nur zu akzeptieren sondern sogar wertzuschätzen sind besondere Unternehmen und besondere Unternehmenskulturen notwendig.<br />
<br />
<h3><a href="https://www.jpattonassociates.com/product-vision-is-science-fiction/" target="_blank">Jeff Patton: Product Vision is Science Fiction</a></h3><h3> </h3>
Mit der Produktvision verhält es sich wie mit vielen nicht abschliessend beschriebenen Fachthemen: je mehr Experten man befragt, desto mehr unterschiedliche Antworten bekommt man. Jeff Patton hat zwar nicht die eine Version auf die sich alle einigen werden, dafür aber eine gute: Seine Produktvision beschreibt eine zukünftige Welt, einschliesslich des zukünftigen Produkts und der Zwecke die es dort erfüllt. Ebenfalls wertvoll ist die Abgrenzung die er vornimmt, u.a. zu Business Goal, Wchstumsziel und Mission Statement. Nicht dass diese Dinge schlecht wären, aber es sind eben keine Produktvisionen.<br />
<br />
<h3><a href="https://charity.wtf/2023/03/08/deploys-are-the-%e2%9c%a8wrong%e2%9c%a8-way-to-change-user-experience/" target="_blank">Charity Majors: Deploys Are The ✨Wrong✨ Way To Change User Experience</a></h3>
Agile Software-Entwicklung hat (Überraschung) mit Software zu tun, und zwar nicht nur damit wie sie entwickelt wird, sondern auch damit, wie die fertig entwickelten neuen Funktionen zum Anwender kommen. Der klassische Weg ist der über den sich Charity Majors hier aufregt: durch Deployments, also dadurch, dass sie auf der Produktionsumgebung ausgerollt werden und ab diesem Moment sichtbar und benutzbar sind. Da das bei zusammenhängenden Funktionalitäten doch wieder zu <a href="https://www.lean-agility.de/2019/07/big-bang-releases.html" target="_blank">Big Bang-Releases</a> führt, zeigt sie einen besseren Weg auf - Continuous Delivery mit <a href="https://www.lean-agility.de/2023/04/feature-toggles.html" target="_blank">Feature Flags</a>.<br />
<br />
<h3><a href="https://hbr.org/2023/04/make-it-safe-for-employees-to-speak-up-especially-in-risky-times" target="_blank"> Constance Noonan Hadley, Mark Mortensen, Amy C. Edmondson: Make It Safe for Employees to Speak Up - Especially in Risky Times</a><br /></h3>
In diesem Artikel eines ganzen Autoren-Kollektivs geht es um psychologische Sicherheit, genauer gesagt darum, wie man sie auch erzeugen kann, wenn die Gesamtsituation gerade kritisch ist. Gerade dann ist es nämlich wichtig, dass alle Beteiligten sich trauen, Missstände anzusprechen und Verbesserungsvorschläge zu machen; wenn das nicht der Fall ist, kann ein Runaway Projekt eintreten, der die Probleme ausser Kontrolle geraten lässt. Spannend ist, dass hier nicht nur erklärt wird wie psychologische Sicherheit gefördert werden kann, sondern auch weshalb sie häufig nicht gegeben ist.<br />
<br />
<h3><a href="https://testing.googleblog.com/2023/04/sensenmann-code-deletion-at-scale.html" target="_blank">Phil Norman: Sensenmann - Code Deletion at Scale </a></h3>
Das hier ist ein wirklich innovativer und bemerkenswerter Ansatz. Phil Normans Firma Google hat erkannt, dass eines der grössten Hindernisse für agile Produktentwicklung die Aufblähung des Quellcodes ist, die zu Unübersichtlichkeit, Unberechenbarkeit und Aufwändigkeit von Änderungen führt. Die Lösung ist radikal: ein Programm namens Sensenmann [sic] identifiziert redundanten oder überflüssigen Code und löscht ihn automatisch. Das kann natürlich nur bei hoher Test- und Monitoring-Abdeckung funktionieren, ist dann aber hocheffektiv.<br />
<br />
<h3><a href="https://trishagee.com/2023/05/29/why-i-prefer-trunk-based-development/" target="_blank">Trisha Gee: Why I prefer trunk-based development</a></h3>
Irgendwann habe ich mal über das Problem von <a href="https://www.lean-agility.de/2015/11/agiles-branchen-und-mergen.html" target="_blank">Branching und Merging</a> geschrieben, mit der Kernaussage, dass Branches keine gute Idee sind. Trisha Gee führt das mit deutlich mehr Detail und Sachverstand aus und hat auch eine Lösung parat wie es besser geht: durch Trunk-based Development (das kontrollierte Einchecken von neuem Code direkt in den Master Branch) wird höhere Geschwindigkeit und Reaktionsfähigkeit erreicht, höhere Stabilität, bessere Zusammenarbeit, bessere Entwicklungspraktiken und geringere <a href="https://www.lean-agility.de/2022/04/technische-schulden.html" target="_blank">technische Schuld</a>. Es lohnt sich also, darauf hinzuarbeiten.<br />
<br />
<h3><a href="https://cloud.google.com/blog/products/application-development/richard-seroter-on-shifting-down-vs-shifting-left?hl=en" target="_blank">Richard Seroter: Shifting left is for suckers. Shift down instead</a></h3>
Noch einmal ein Bericht von Google. Laut Richard Seroter wird die Idee der <a href="https://www.lean-agility.de/2022/08/fullstack-t-shape-pi-shape.html" target="_blank">Fullstack- und T-Shape-Skills</a>, durch die Personen an möglichst vielen Themengebieten mitarbeiten können, dort eher kritisch gesehen, da sie das Risiko eines zwar breiten, dafür aber nicht besonders tiefgehenden Wissens mit sich bringt. Seine Alternative nennt er Shift Down, und sie besteht daraus, dass den Entwicklern in seiner Firma möglichst viel Arbeit abgenommen wird indem sie in einfach bedienbare Plattform-Services ausgelagert wird. So kann die kognitive Last gering bleiben und die Expertise hoch.<br />
<br />
<h3><a href="https://vitalitychicago.com/blog/should-we-fire-all-the-agile-coaches/" target="_blank">Anthony Mersino: Should We Fire All the Agile Coaches?</a><br /></h3>
Einer der interessanteren Trends des letzten Jahres sind die grossflächigen Entlassungen von Agile Coaches und Scrum Mastern, die in mehreren deutschen und amerikanischen Konzernen stattgefunden haben. Viele der Reaktionen darauf beschränken sich auf ein <a href="https://www.lean-agility.de/2021/08/wie-man-agile-fur-tot-erklaert.html" target="_blank">marktschreierisches füt tot erklären der Agilität</a>, es gibt aber auch differenzierte Analysen. Diese hier von Anthony Mersino gehört in die zweite Gruppe. Verkürzt gesagt zeigt er Gründe auf, wegen denen diese Rollen als nicht mehrwertstiftend wahrgenommen und daher in Krisenzeiten abgebaut werden.<br />
<br />
<h3><a href="https://hbr.org/2023/11/lessons-from-the-u-s-navy-on-building-a-culture-of-learning" target="_blank">Bill Lescher: Lessons from the U.S. Navy on Building a Culture of Learning</a><br /></h3>
Und noch einmal ein Praxis-Bericht, diesesmal nicht von Google sondern von der amerikanischen Marine, bzw. deren Programm zur Verbesserung der Einsatzfähigkeit ihrer Flugzeuge. Vieles davon kennt man aus agilen Teams, z.B. das Delegieren von Verantwortung, das datengetriebene Vorgehen und das Suchen nach Lösungen statt nach Schuldigen. Darüber hinaus gibt es in Bill Leschers Artikel aber auch interessante neue Aspekte, wie z.B. den, dass dort bei den Beurteilungen der verantwortlichen Personen das Systemverständnis und die Prognose-Genauigkeit ähnlich wichtig sind wie die Erfolgsquote.<br />
<br />
<h3><a href="https://medium.com/the-liberators/what-3-years-of-our-own-scientific-research-brought-4ede457784f8" target="_blank">Barry Overeem, Christiaan Verwijs: What 3 Years Of Our Own Scientific Research Brought</a><br /></h3>
Ein Hoch auf die Wissenschaft! Dass zu vieles von dem, was Agile Coaches und Scrum Master für richtig halten, eher auf <a href="https://www.lean-agility.de/2020/02/anekdotische-evidenz.html" target="_blank">anekdotischer Evidenz</a> als auf überprüfbaren Daten beruht wird oft beklagt - Barry Overeem und Christiaan Verwijs tun etwas dagegen. Zusammen mit der Universität Aalborg haben sie einige der gefühlten Wahrheiten einer wissenschaftlichen Überprüfung unterzogen, mit zum Teil überraschenden Ergebnissen. Von derartigen Untersuchungen bräuchte es deutlich mehr.<br />Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-1429411916217980182023-12-29T09:30:00.002+01:002023-12-29T10:22:12.708+01:00Kommentierte Links (CVIII)<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjNqFxvJDcSD5FwVoTuDK_FgdQAIkyyvXjs5tGJ-dByGSrwXlD1MxQ_BHOWlFM3rJ4tCRi97No4ge7Wd3rS7EMrBEkmiBs1Shpf7222e25f18aKl4YAGxAtaGtRJKjd7ZJdDaj-MzYhz59XaS24bAupLKVyZkbO6ylFDagrNvKfEc_z9NGgWgIgiwBmLg/s3320/Lampen.jpg" style="display: block; margin-left: auto; margin-right: auto; padding: 1em 0px; text-align: center;"><img border="0" data-original-height="2078" data-original-width="3320" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjNqFxvJDcSD5FwVoTuDK_FgdQAIkyyvXjs5tGJ-dByGSrwXlD1MxQ_BHOWlFM3rJ4tCRi97No4ge7Wd3rS7EMrBEkmiBs1Shpf7222e25f18aKl4YAGxAtaGtRJKjd7ZJdDaj-MzYhz59XaS24bAupLKVyZkbO6ylFDagrNvKfEc_z9NGgWgIgiwBmLg/w640-h400/Lampen.jpg" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Bild: <a href="https://unsplash.com/photos/_z0DiiaIhB4" target="_blank">Unsplash / Fabio Bracht</a> - <a href="https://unsplash.com/license" target="_blank">Lizenz</a></td></tr></tbody></table>
Das Internet ist voll von Menschen, die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.<br />
<br />
<h3><a href="https://blog.staysaasy.com/p/practical-ways-to-increase-product" target="_blank">Stay Saasy: Practical Ways To Increase Product Velocity</a></h3>
Die Velocity, also die Durchsatzmenge erledigter Arbeit pro Zeiteinheit, ist häufig ein kontroverses Thema, da viele Teams darin ein Werkzeug sehen, mit dessen Hilfe sie in die Akkordarbeit getrieben werden sollen. Das kommt auch tatsächlich vor, allerdings nur dort, wo das "schneller Arbeiten" als einziges Mittel gesehen wird, die Velocity zu erhöhen. Dass eine Steigerung auch durch Arbeit am System, an den Kommunikationswegen oder an der Technologie erreicht werden kann, wird zu häufig übersehen. Um so besser, dass Stay Saasy einiges davon zusammengefasst hat.<br />
<br />
<h3><a href="https://www.indiskretionehrensache.de/2023/12/home-office-stoppen/" target="_blank">Thomas Knüwer: Wie bekommen Unternehmen Mitarbeiter zurück ins Büro?</a><br /></h3>
Man bekommt es aus fast allen Firmen mit - die Versuche, die Mitarbeiter zu regelmässiger Anwesenheit im Büro zu überreden, haben entweder nur geringe Erfolge oder erzielen diese mit dem Preis von Unzufriedenheit und Konflikten. Die Lösung, die Thomas Knüwer präsentiert, um die Motivation für die Präsenzarbeit zu erhöhen, scheint zuerst offensichtlich: man sollte die Büros so gestalten, dass die Menschen gerne in ihnen arbeiten. Der entscheidende Punkt ist seine These (die ich teile): dafür müssten die Grossraum-Büros wieder in kleinere Einheiten umgebaut werden, so wie sie früher waren.<br />
<br />
<h3><a href="https://cutlefish.substack.com/p/tbm-259-the-predictability-trap" target="_blank">John Cutler: The Predictability Trap</a><br /></h3>
Das was John Cutler hier ausspricht, dürfte für viele klassisch sozialisierte Manager hart zu schlucken sein: je mehr man Umsetzungsteams dazu drängt, prognostizierte Lieferzeitpunkte und -umfänge einzuhalten, desto geringer ist die Wahrscheinlichkeit, dass das dauerhaft gelingen wird. Denn gerade das, was vernachlässigt wird, wenn alle Energie in die pünktliche Fertigstellung des nächsten Features fliessen muss, ist das was auf Dauer für Lieferfähigkeit sorgt: Aufräum- und Reparatur-Arbeiten am Prozess, an der Technik und am Produkt.<br />
<br />
<h3><a href="https://tidyfirst.substack.com/p/canon-tdd" target="_blank">Kent Beck: Canon TDD</a></h3>
Gerade bei den einfachsten Begriffen können mitunter die grössten Missverständnisse auftreten. Irgendwie erscheint alles offensichtlich und naheliegend, so dass man die Dinge einfach tun kann ohne darüber nachzudenken - und ohne es zu merken ist man plötzlich in der falschen Richtung unterwegs. Kent Beck ist aufgefallen, dass das auch beim von ihm entwickelten Test Driven Development (TDD) immer wieder der Fall ist. Aufgrunddessen hat er die Idee und das Vorgehen noch einmal kompakt zusammengefasst, so dass jeder sich mit dem Ansatz im Original vertraut machen kann.<br />
<br />
<h3><a href="https://www.mountaingoatsoftware.com/blog/how-much-can-you-really-tinker-with-scrum" target="_blank">Mike Cohn: How Much Can You Really Tinker with Scrum?</a></h3>
Ein grosser Klassiker. Welche Bestandteile von Scrum sind optional und können weggelassen werden und ohne welche geht es nicht? Mike Cohn beantwortet diese Fragen nicht nur (zumindest anhand einiger der am häufigsten gefragten), sondern er tut es auch noch multimedial - man kann seine Antworten entweder lesen oder als Kurzvideo ansehen und anhören.<br />Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.comtag:blogger.com,1999:blog-6023249185450652726.post-34987989403578153112023-12-25T10:00:00.002+01:002023-12-25T10:00:00.239+01:00Agile Night Xmas<p>Die Weihnachtsfeiertage sind viel zu beschaulich für steile Thesen, tiefschürfende Analysen oder methodische Meta-Betrachtungen. Daher gibt es heute etwas ganz anderes: Musik. Adam Janosch setzt sich für die agile Festtagsstimmung ans Klavier.<br /></p>
<p><br /></p>
<iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/tDKRka-XnWU?si=TRFUiq2gDLsYs1I9" title="YouTube video player" width="560"></iframe>
<p><br /></p>
<p>Je nach persönlicher Vorliebe empfehle ich übrigens, zu seinem Lied mit Glühwein, Eggnogg oder Weihnachtsbock anzustossen. Der stimmungshebende Effekt wird dadurch nochmal verstärkt.<br /></p>Felix Steinhttp://www.blogger.com/profile/14897866756986043443noreply@blogger.com