Gerrit Beine http://gerritbeine.com Software-Architektur & Agile Methoden Fri, 04 Sep 2015 16:53:00 +0000 de-DE hourly 1 Kontinuierliche Verbesserung und Wachstum http://gerritbeine.com/2015/07/kontinuierliche-verbesserung-und-wachstum/ http://gerritbeine.com/2015/07/kontinuierliche-verbesserung-und-wachstum/#comments Thu, 23 Jul 2015 16:03:50 +0000 https://gerritbeine.com/?p=459 Weiterlesen ]]>

„KVP beruht auf der Annahme, das Wachstum der einzig relevante Faktor eines Unternehmens zur Steigerung seiner Wirtschaftlichkeit ist. KVP ist endlich und somit zum Scheitern verurteilt.“

Eine herrliche These, sofern man diese Behauptung als solche bezeichnen mag. Beruht KVP auf der Annahme, dass Wachstum der einzig relevante Faktor ist? Nein, definitiv nicht. Denn KVP macht sich um ziemlich viel Gedanken, aber nicht um Wachstum. Bei KVP geht es um Qualität von Dienstleistungen, Prozessen und Produkten. Aber wahrlich nicht um Wachstum.

Das wird als Seiteneffekt gerne in Kauf genommen, ist aber nicht das direkte Ziel von KVP.

Im Artikel wird Karl zitiert mit der Aussage, dass „unendliches Wachstum in einer endlichen Welt nicht funktionieren kann“. Das hört man sehr oft, ist aber, sofern es um Ökonomie geht, falsch. Natürlich ist es nicht möglich, das physikalische Entitäten in einer endlichen Welt unendlich wachsen. Ökonomie ist aber keine physikalische Entität, sondern ein virtuelles Modell. Das bedeutet, dass wir Ökonomie nur anhand ihrer Wirkung erleben und diese Wirkungen abstrakt beschreiben. Man kann davon ausgehen, dass eine Ökonomie, die auf dem Verbrauch von Ressourcen basiert, nur so lange funktioniert, wie diese Ressourcen zur Verfügung stehen. Im Falle eines kontinuierlichem Wachstums beschleunigt eine solche Ökonomie ihren Untergang, je näher sie ihm kommt.

Nun ist Ökonomie aber auch ein adaptives System, sie hat die Fähigkeit sich anzupassen. Man könnte sagen, der Ökonomie als solcher ist ein KVP innewohnend. Eine Ökonomie, die auf dem Verbrauch von Ressourcen begründet ist, hat die Möglichkeit, sich zu wandeln, nämlich zu einer Ökonomie, die auf der Transformation von Ressourcen beruht. Viele Ressourcen haben Eigenschaften, die eine beliebig häufige Wiederverwendung ermöglichen oder können durch Alternativen ersetzt werden. Damit ist die Existenz einer (ursprünglich Ressourcen verbrauchenden) Ökonomie in einer endlichen Welt auf unbestimmte Zeit möglich. Jetzt kommt die Frage nach dem Wachstum und hier sei – unter vielen anderen guten Büchern zu diesem Thema – Tomáš Sedláčeks „Die Ökonomie von Gut und Böse“ empfohlen.

Das ökonomische Wachstum das wir heute erleben ist zum Einen ein Wachstum der Dienstleistungen, für die ein Ende nicht bestimmbar ist, denn das würde bedeuten, dass wir alle denkbaren Dienstleistungen schon kennen. Dass das nicht der Fall ist, zeigt sich immer wieder auf’s Neue und kann gut durch die Five Orders of Ignorance erklärt werden. Zum Anderen beruht das Wachstum auf einer kontinuierlichen Entwertung des Geldes, das dem Prinzip unseres Schuldgeldsystems anzulasten ist. Das kann man gut oder schlecht finden, es funktioniert bisher ausreichend gut und sämtliche Adaptionen davon (Schwundgeld, Regionalgeld etc. ist nichts anderes als kontinuierlich entwertetes Geld) basieren auf dem gleichen Prinzip. Wer sich dafür interessiert, möge meine Thesis über den Gold Standard lesen, da habe ich das recht ausführlich erklärt.

Nun, zurück zur ursprünglichen Aussage. Diese ist meiner Meinung nach grundlegend falsch, weil sie von zwei falschen Prämisse ausgeht:

  1. KVP geht nicht von der erwähnten Annahme aus.
  2. KVP ist nicht endlich, weil selbst wenn KVP von dieser Annahme ausgehen würde, weder dem Wachstum noch den Verbesserungsmöglichkeiten Grenzen gesetzt sind.
]]>
http://gerritbeine.com/2015/07/kontinuierliche-verbesserung-und-wachstum/feed/ 0
Der hyperbolische Thread-Koeffizient – über Wirkungsgrad von Managern in agilen Organisationen http://gerritbeine.com/2015/07/der-hyperbolische-thread-koeffizient-ueber-wirkungsgrad-von-managern-in-agilen-organisationen/ http://gerritbeine.com/2015/07/der-hyperbolische-thread-koeffizient-ueber-wirkungsgrad-von-managern-in-agilen-organisationen/#comments Mon, 13 Jul 2015 17:05:37 +0000 https://gerritbeine.com/?p=429 Weiterlesen ]]>

Ich kenne viele Manager, die KPIs lieben. Je mehr Faktoren auf eine Zahl reduziert werden, umso besser ist der KPI.

Nachdem ich mich in letzter Zeit häufiger im Umfeld der Organisationsentwicklung tummeln durfte, kam ich auf die Idee, doch einen KPI zu nutzen, um den Wirkungsgrad von Managern zu messen. Der Hintergrund meiner Überlegungen war, dass ich regelmäßig mit Managern sprechen muss, wenn eine Veränderung der Organisation notwendig ist. Manchmal muss ich dafür sehr lange auf einen Termin bei so einem Manager warten, was natürlich besonders in Organisationen, die gerne agil werden oder sein wollen, problematisch ist. Eventuell hat das Problem die Organisation schon überholt, wenn ich den Termin bekommen habe.

Hoher HTK

Ein hoher Hyperbolischer Thread-Koeffizient bedeutet eine geringe Wirksamkeit.

Nach einigem Nachdenken und der Lektüre von Gunter Duecks Meisterwerk Schwarmdumm bin ich dann zum Schluss gekommen, dass dieser Wirkungsgrad mit der Warteschlangentheorie zusammen hängt. Ein Manager, der eine kurze Queue und damit viel freie Zeit hat, ist wirksamer, als ein Manager, der eine lange Queue hat. Auf letzteren muss ich warten, wenn ich ein Anliegen habe, das reduziert seine Wirksamkeit. Der Wirkungsgrad von ersterem ist höher, weil er zeitnah reagieren kann.

Aber wie kann man das jetzt messen? Ich habe mich an meine eigene Zeit als Geschäftsführer erinnert und diese mit meinen Beobachtung vieler Manager verglichen. Dann kam mir die Idee: die ideale Quelle zur Berechnung der Wirksamkeit eines Managers ist sein Outlook-Kalender.

Ich habe mir dazu folgende Formel überlegt:
Die Wirksamkeit eines Managers verhält sich umgekehr proportional zu seinem Hyperbolischen Thread-Koeffizient [1]. Der HTK berechnet sich aus dem Median der Anzahl der Termine im Outlook pro Woche hoch dem Maximum der parallelen Termine innerhalb eines Kalenderjahres.

Die Wirksamkeit ist dann: \eta = \frac{1}{HTK} bzw. \eta = \frac{1}{MOT^{MPT}}

Wobei gilt:
MOT = med(Anzahl\ der\ Termine\ im\ Outlook\ pro\ Woche) und MPT = max(Gleichzeitig\ parallele\ Termine\ innerhalb\ eines\ Kalenderjahres)

Niedriger HTK

Ein niedriger Hyperbolischer Thread-Koeffizient bedeutet einen hohen Wirkungsgrad.

Damit hat jetzt jeder Manager einen persönlichen KPI zur Bewertung der eigenen Leistung! Und ich habe ihn erfunden.

[1] Der Begriff Hyperbolischer Thread-Koeffizient setzt sich aus mehreren wichtigen wissenschaftlichen Komponenten zusammen. Thread leitet sich aus der Tatsache ab, dass die Anzahl der parallelen Aktivitäten eine wichtige Rolle bei der Berechnung spielen. Hyperbolisch ist der Koeffizient, weil er zeigt, wie stark der oder die Betreffende es mit der eigenen Wirksamkeit übertreibt.

]]>
http://gerritbeine.com/2015/07/der-hyperbolische-thread-koeffizient-ueber-wirkungsgrad-von-managern-in-agilen-organisationen/feed/ 0
Planning Pattern II – Test Driven Sprint Planning http://gerritbeine.com/2015/07/planning-pattern-ii-test-driven-sprint-planning/ http://gerritbeine.com/2015/07/planning-pattern-ii-test-driven-sprint-planning/#comments Sun, 12 Jul 2015 16:54:38 +0000 https://gerritbeine.com/?p=407 Weiterlesen ]]>

Im ersten Teil dieser Reihe habe ich erklärt, wie ein Team im Sprint Planning dafür sorgt, dass während des Sprints ein Flow entsteht. Diesmal möchte ich darauf eingehen, wie die Struktur auf dem Scrum Board den Verlauf des Sprints beeinflusst und wie man im Sprint Planning darauf Einfluss nehmen kann.

Auch wenn Scrum Teams in der Regel cross functional sind, ist es doch weit verbreitet, dass es eine Aufteilung der Rollen zwischen Testern und Entwicklern gibt. Für viele Teams ist das auch völlig in Ordnung, wenn die Zusammenarbeit klappt. Bei einem Team, für das ich als ScrumMaster arbeiten konnte, hatte ich die Gelegenheit, mit dieser Zusammenarbeit zu experimentieren und mit dem Team gemeinsam das entwickelt, was wir später als Test Driven Sprint Planning bezeichnet haben.

Generische Test Tasks

Generische Test Tasks

Zunächst verliefen die Plannings in diesem Team so wie ich es auch schon von anderen Teams kannte: Der Product Owner präsentierte seine Storys, die Entwickler schnitten Tasks und am Ende klebten die Tester drei Zettel ans Board auf denen stand: „Test Design“, „Test Automation“, „Test Execution“. Solche generischen Tasks sind natürlich wenig hilfreich, wenn man einen guten Flow im Sprint haben möchte und sie geben auch kein Gefühl dafür, was schon erreicht wurde und was noch fehlt.

Im Laufe der Zeit gelang es uns, das Planning umzudrehen. Nachdem der Product Owner seine Storys präsentiert hatte, übernahmen die Tester die Führung des Plannings. Anhand der Akzeptanzkriterien entwickelten sie Testideen. Das waren grobe Beschreibungen eines Tests, die auf die gleichen Post-Its passten, wie die Tasks.

Scrum Board mit Testideen

Scrum Board mit Testideen

Die Testideen klebten wir neben die Storys untereinander und überlegten dann, welche konkreten Tests sich daraus ergeben würden – und was implementiert werden müsste, damit der Test grün würde. Damit erarbeiteten Tester und Entwickler gemeinsam eine Reihe von Aufgaben zu jeder der Testideen, die dann in eine Zeile neben jede Testidee passten. Das Scrum Board entwickelte ganz von selbst eine sehr übersichtliche Struktur, die es erlaubte, Fortschritt im Sprint und auch Probleme während des Tests für alle im Team extrem gut sichtbar zu machen.

Diese Erkenntnis lieferte uns dann das zweite Planning Pattern:

Entwickle aus den Akzeptanzkriterien Testideen und überlasse die Führung des Sprint Plannings den Testern. Entwickler machen die Tests grün.

Der Ansatz hat nicht nur auf dem Scrum Board zu einer Veränderung geführt. Auch während des Sprints lief die Zusammenarbeit besser. Die Idee des Test Driven Development funktioniert also nicht nur mit Unit Tests, sondern lässt sich auch auf anderen Abstraktionsebenen anwenden.

Dieser Artikel erschien zuerst im adesso Blog.

]]>
http://gerritbeine.com/2015/07/planning-pattern-ii-test-driven-sprint-planning/feed/ 0
Planning Pattern I – Planen für den Flow http://gerritbeine.com/2015/07/planning-pattern-i-planen-fuer-den-flow/ http://gerritbeine.com/2015/07/planning-pattern-i-planen-fuer-den-flow/#comments Sat, 11 Jul 2015 17:05:31 +0000 https://gerritbeine.com/?p=400 Weiterlesen ]]>

In dieser Artikelreihe möchte ich einige Pattern vorstellen, die agilen Teams helfen können, die Ergebnisse ihrer Sprint Plannings zu optimieren. Die meisten der Pattern sind bei der Arbeit mit Scrum Teams entstanden, sie lassen sich aber auch gut für Extreme Programming oder Kanban adaptieren.

20 Tasks am Board

20 Tasks am Board

Vor einigen Jahren kam ich als neuer Scrum Master zu einem Team, das schon eine geraume Weile zusammenarbeitete. Das Team arbeitete mit 2-Wochen-Sprints, hatte ein dreispaltiges Scrum Board, also auf den ersten Blick nichts außergewöhnliches. Allerdings hatte das Team in den letzten drei Sprints sein Commitment nicht geschafft. Was mich erstaunte, denn Aufgaben erschienen mir durchaus im Bereich des Machbaren und das Team war fit.

Als neuer Scrum Master halte ich mich immer erst mal mit Kommentaren zurück und beobachte viel. Beim Sprint Planning war ich dann erstaunt, dass das Team fast einen ganzen Tag dafür aufwendete und am Ende lediglich 20 Tasks am Scrum Board klebten. Ich fragte das Team also, ob sie sich sicher seien, dass das so ok war. Das Team meinte, ja, das wäre OK so. Es kam, wie es kommen musste – der Sprint lief schief, weil sich die Teammitglieder die ganze Zeit nur gegenseitig auf den Füßen standen und Tasks ewig „In Progress“ waren.

In einer Retrospektive konfrontierte ich das Team mit der Idee, dass ein Task nicht länger als einen Tag dauern sollte. Diese Idee kommt ja nicht von ungefähr, sie ist der Garant für einen guten Flow während des Sprints. Wir diskutierten eine ganze Weile darüber und schließlich kam eine recht interessante Betrachtung dabei heraus:

  • 1 Task <= 1 Tag
  • 1 Sprint = 10 Tage
  • 1 Team = 7 Personen
  • 1 Person benötigt >=10 Tasks (folgt aus (1) & (2))
  • 7 Personen benötigen >=70 Tasks (folgt aus (3) & (4))

Eines der Teammitglieder war Physiker und konnte das auf diese Weise kompakt zusammenfassen. Ein Team mit sieben Personen benötigt für einen 2-Wochen-Sprint mit 10 Arbeitstagen mindestens 70 Tasks am Scrum Board, um sicherzustellen, dass ein Task nicht mehr als einen Tag in Anspruch nimmt.

Diese Erkenntnis ist auch bereits das erste Planning Pattern:

Schneide die Tasks so, dass ihre Anzahl mindestens der Anzahl der Arbeitstage im Sprint multipliziert mit der Anzahl der Teammitglieder entspricht.

200 Tasks am Board

200 Tasks am Board

Das Team nahm die Herausforderung an und beim nächsten Planning befanden sich statt 20 plötzlich fast 200 Tasks auf dem Scrum Board. Nach einer Weile hat sich die Menge der Tasks auf 90 bis 120 Tasks pro Sprint eingependelt. Die kleinen Aufgaben führten zu einer sehr entspannten und kontinuierlichen Abarbeitung während des Sprints – das Team hatte seinen Flow gefunden. Ein angenehmer Nebeneffekt war, dass das Sprint Planning sich drastisch verkürzte.

Dieser Artikel erschien zuerst im adesso Blog.

]]>
http://gerritbeine.com/2015/07/planning-pattern-i-planen-fuer-den-flow/feed/ 1
Doch, das geht schon so. Eine Lanze für agile Job-Titel. http://gerritbeine.com/2015/06/doch-das-geht-schon-so-eine-lanze-fuer-agile-job-titel/ http://gerritbeine.com/2015/06/doch-das-geht-schon-so-eine-lanze-fuer-agile-job-titel/#comments Fri, 26 Jun 2015 11:07:48 +0000 https://gerritbeine.com/?p=394 Weiterlesen ]]>

Im Laufe der Woche kam ein Artikel von Patrick Koglin in meinem Newsreader reingeflogen. Patrick beschreibt die Verwendung von Bezeichnungen wie Senior Scrum Master oder Junior Scrum Master als schlimm. Ich lese Patricks Artikel gern und teile seine Meinung häufig, aber in diesem Fall muss ich vehement mein Veto einlegen.

Zunächst der Aspekt, in dem ich dem Artikel zustimme: Nur, weil ein Board im Raum steht, bin ich nicht agil. Agil ist eben nicht Cargo Cult, sondern eine echte Kultur, ein Mindset. Ebenso denke ich, dass in einem agilen Team einem jungen Entwickler ebenso zugehört werden muss, wie der erfahrenen Kollegin und beide auf Augenhöhe zusammenarbeiten sollten. Gleiches gilt für Scrum Master, Product Owner und jeden Manager. Sowohl innerhalb eines Teams als auch in der Umwelt.

Dafür muss ich aber nicht agil sein, das ist schlicht und einfach der Respekt vor anderen Menschen, der diese Sichtweise gebietet.

Der Aspekt, bei dem ich grundlegend anderer Meinung bin, ist, dass es keine Senior oder Junior Scrum Master als Job-Bezeichnung geben darf. Ich bin der Meinung, dass so etwas völlig ok ist und viele Organisationen es sogar unbedingt benötigen. Ich zitiere gerne Tucholsky mit  „Erfahrung bedeutet nichts, man kann eine Sache auch dreißig Jahre lang schlecht machen.“ Für mich bedeutet das, dass Bezeichnungen wie Senior nicht an das Dienstalter gekoppelt sein dürfen.

Menschen orientieren sich an solchen Bezeichnungen, sie sind Teil der Struktur einer Organisation. Wenn ich dieses Argument aus dem Hut ziehe, kommt meistens das Gegenargument, dass in solchen Organisationen die Kultur kaputt sei. Und das ist  in meinen Augen schlimm.

Ich finde es völlig ok, zwischen Junior und Senior Scrum Mastern zu unterscheiden. Der Junior Scrum Master ist einer, dem ich helfe, großartig zu werden. Der Mensch ist es schon, der Scrum Master muss einiges erleben. Und damit der Scrum Master das kann, bekommt er Unterstützung von einem Senior, der schon war, wo der Junior noch hin will. So einfach ist das.

Und ja, ich finde es absolut gerechtfertigt, wenn jemand stolz darauf ist, ein Senior Scrum Master zu sein und sich diese Bezeichnung verdient hat, indem er ganz viele Teams großartig gemacht hat und jede Menge unerfahrene Scrum Master an seinem Wissen und Können hat teilhaben lassen. Das ist Agilität.
Die Ablehnung von Job-Titeln aus Prinzip ist hingegen Cargo Cult.

]]>
http://gerritbeine.com/2015/06/doch-das-geht-schon-so-eine-lanze-fuer-agile-job-titel/feed/ 2
User Experience – ein cooles Thema http://gerritbeine.com/2015/06/user-experience-ein-cooles-thema/ http://gerritbeine.com/2015/06/user-experience-ein-cooles-thema/#comments Mon, 01 Jun 2015 18:09:49 +0000 https://gerritbeine.com/?p=389 Weiterlesen ]]>

Ein Geschichte, wie sie jeden Tag passieren kann, wenn man als Consultant unterwegs ist: Mitten in der Nacht kommt man von einer langen Zugfahrt müde in sein Hotel. Vorher noch zehn Minuten durch den Regen gelaufen, ist man pitschnass. Der Checkin verläuft zäh wie üblich und dann erreicht man schlussendlich doch sein Zimmer.

Nur, dass es da tierisch kalt ist. Zum Zähneklappern kalt. Aber es ist zu spät, um mit der Rezeption zu diskutieren, also ab ins Bett, die zweite Decke drüber gezogen und Augen zu.

Nächster Tag. Nachfragen an der Rezeption, es ist kalt im Zimmer. Die Antwort ist nicht sonderlich befriedigend. Das sei normal, sagt man dort, denn die Heizung heizt nicht mehr sondern kühlt. Da es um diese Jahreszeit eigentlich warm sei, wäre das auch in Ordnung so. Und es ist kompliziert die Heizung umzustellen.

Was hat das mit User Experience zu tun? Ganz einfach: diese Heizungsanlage ist ein Beispiel für eine miserable User Experience. Vermutlich, weil hier der zentrale User bei der Erstellung gar keine Rolle gespielt hat. Der wichtigste User einer Heizung in einem Hotel ist der Gast. Und als Gast wünscht man sich, dass die Heizung heizt, wenn es draußen kalt ist. Und dass sie kühlt, wenn es draußen warm ist. Warmes und kaltes Wetter richten sich aber nicht nach dem Kalender. Wetter passiert einfach.
Der Hausmeister ist, auch wenn das vielleicht naheliegend ist, nicht der zentrale User der Heizungsanlage. Er bedient sie, aber das macht nur einen geringen Teil der Nutzung aus. Für ihn ist es bequem, dass die Heizung sich nach dem Kalender richtet, da muss er sich nicht darum kümmern. Für die Gäste ist es unbequem.

Was kann man aus dieser Erfahrung lernen? Ganz einfach: Es ist wichtig, die zentralen User eines Systems zu erkennen, auch wenn sie auf den ersten Blick nur passive Rollen spielen. Wenn deren User Experience miserabel ist, führt das zu Ablehnung des gesamten Systems. So auch heute früh an der Rezeption. Es haben sich viele Gäste beschwert.Man hätte auch eine Heizung mit Temperatursensor einbauen können. Aber davon hätte der Hausmeister nix gehabt.

]]>
http://gerritbeine.com/2015/06/user-experience-ein-cooles-thema/feed/ 1
Artikel über Antifragilität in der Softwareentwicklung http://gerritbeine.com/2015/05/artikel-ueber-antifragilitaet-in-der-softwareentwicklung/ http://gerritbeine.com/2015/05/artikel-ueber-antifragilitaet-in-der-softwareentwicklung/#comments Wed, 20 May 2015 14:34:06 +0000 https://gerritbeine.com/?p=377 Weiterlesen ]]>

Im Business Technology Magazin 1.15 ist ein Artikel von mir zum Thema Antifragilität und deren Bedeutung für die Softwareentwicklung erschienen. Der gleiche Artikel steht seit gestern auf jaxenter.de zur Verfügung.

Die wissenschaftlichere Version davon, die Prof. Wolfgang Golubski und ich auf der Multikonferenz Software Engineering & Management vorgestellt hatten, ist ebenfalls online in der Electronic Library of Mathematics verfügbar.

Ich freue mich natürlich über Feedback!

]]>
http://gerritbeine.com/2015/05/artikel-ueber-antifragilitaet-in-der-softwareentwicklung/feed/ 0
Bertrand Meyer: Agile! The Good, the Hype and the Ugly http://gerritbeine.com/2015/04/bertrand-meyer-agile-the-good-the-hype-and-the-ugly/ http://gerritbeine.com/2015/04/bertrand-meyer-agile-the-good-the-hype-and-the-ugly/#comments Sun, 26 Apr 2015 08:54:00 +0000 https://gerritbeine.com/?p=321 Weiterlesen ]]>
Bertrand Meyer: Agile! The Good, the Hype and the Ugly

Bertrand Meyer: Agile! The Good, the Hype and the Ugly

Das erste Buch, dass sich objektiv und neutral mit Agilität auseinandersetzt, ist mir natürlich eine ebenso objektive und neutrale Rezension wert – und ich werde sie inkrementell verfassen.

Nachdem ich in einem Kommentar zu einem infoQ-Artikel geschrieben habe, dass ich eine Rezension verfassen würde, bin ich gerade dabei das Buch zu lesen.

Eigentlich habe ich Bertrand Meyer immer geschätzt, seine Bücher über Objektorientierte Softwareentwicklung haben mich im Studium begleitet. Er gehörte zu den Großen.

Jetzt habe ich das erste Kapitel gelesen und muss feststellen: Meyer demontiert sich in unerhörtem Ausmaß selbst. Nicht nur, dass schon in der Einleitung deutlich wird, dass er die Grundlagen agiler Methoden nicht verstanden hat, er definiert vielmehr in einer Auflistung diverser Praktiken aus dem agilen Umfeld alles als „gut“, das seiner Meinung nach nicht aus der agilen Community entstammt und alles als „schlecht“, das seiner Meinung eben aus dieser Community kommt.

Dabei interessiert ihn nicht, ob die betreffende Praktik sich irgendwo bewährt hat (User Story) oder tatsächlich von Agilisten zuerst beschrieben wurde (Continuous Integration). Ersteres ist schlecht, weil das eben so ist, letzteres ist nicht neu, weil es gut ist und es damit nicht agile sein kann.

Ich bin jetzt erst mit dem ersten Kapitel durch und über alle Maßen enttäuscht. Ich lese in diesem Buch vor allem Frust, aber wenig Sachlichkeit.

Kapitel 2: Dekonstruktion agiler Texte

Weil es so spannend war, habe ich gestern auch noch das zweite Kapitel gelesen. Hier beschäftigt sich Meyer mit der Dekonstruktion von Texten aus dem Umfeld der agilen Community.

Und er macht den gleichen Fehler, den viele Dekonstruktivisten machen: Er verzirkelt sich. Um zu zeigen, dass solche Texte nicht aussagefähig sind, zieht er ein Zitat aus „Succeeding with Agile“ von Mike Cohn heran, in dem eine Anekdote zur Diskussion gesprochenes vs. geschriebenes Wort berichtet wird.
Meyer meint nun, das Cohn mit dieser Anekdote “beweisen“ wolle, dass das gesprochene dem geschriebenen Wort überlegen ist und folgert daraus, dass in der agilen Community anekdotische Evidenz als Beweismittel betrachtet wird. Das lustige hieran ist, dass Meyer selbst eine Anekdote (ich habe bei Mike Cohn gelesen…) als Grundlage einer Generalisierung heranzieht (…deshalb ist das in allen Texten von Agilisten so). Gänzlich lächerlich wird Meyers zynische Dekonstruktion aber, wenn man weiß, das Cohn gerade mit diesem Zitat nichts beweisen wollte, sondern genau das Gegenteil: einen vermeintlich bereits erbrachten Beweis (Geschriebenes ist klar und eindeutig) widerlegen wollte. Und dazu reicht eine einzige Anekdote eben aus. Das sollte Meyer als Wissenschaftler wissen.

Als Meyer dann noch meint, dass „in den meisten seriösen Projekten“ irgendwann alle Leute mal danach schreien, man möge „es“ doch aufschreiben, damit „alle“ die Chance hätten, „es“ zu verstehen und nachzuvollziehen, konnte ich nur noch den Kopf schütteln. In den seriösen Projekten, in denen ich war, erlebte ich, nach dem Dinge aufgeschrieben waren, sehr oft die Situation, dass Leute nach der Lektüre über einen Text sprechen wollten, um ihn richtig zu verstehen.

Für Meyer ist es jedenfalls keine Frage: Weniger reden, mehr schreiben. Das ist eindeutiger und sicherer. Mit eigenen Erfahrungen kann ich das nicht bestätigen. Ich habe das differenzierter erlebt: Schreibe so viel, dass man mit einem kurzen Gespräch Verstehen bei allen Beteiligten erreichen kann.

Ach, und eines hat Meyer auch nicht verstanden: In agilen Projekten brauchen wir deshalb keine Feinspezifikation, weil wir automatisierte Tests haben. Die sind zwar zwangsläufig immer nur Beispiele für Anwendungsszenarien, helfen aber Entwicklern beim Verstehen viel mehr als abstrakte und generische Anforderungen, wie Meyer sie favorisiert.

Meine Meinung zu dem Buch ist auch nach dem zweiten Kapitel nicht besser geworden. Das sind jetzt immerhin 28% – ich bin total auf den Rest gespannt.

Kapitel 3: Big Upfront Anything

Meyers Buch zu lesen wird nicht leichter. Im dritten Kapitel lässt er sich über die These aus, dass Agilisten ein Feindbild im Big Upfront Anything haben.

Er greift erneut auf das Mittel der Dekonstruktion agiler Texte zurück, diesmal mit dem Beispiel des ‚Slander by Association‘. Einige Seiten lang hält sich Meyer daran auf, zu dass Agilisten ‚Wasserfall‘ mit ‚Vorhersagend‘ gleichsetzen – er hat das in einem(!) Buch von Sutherland gelesen.

Neben der Notwendigkeit von Requirements, Architektur und CMMI, die Meyer vor allem mit ihrer Notwendigkeit begründet (Zirkelschlüsse hat er Agilisten bis zum dritten Kapitel noch nicht vorgeworfen), gibt es inhaltlich kaum Neues. Bemerkenswert sind seine Sprünge in der Abstraktionsebene. Einmal zeigt er anhand eines Code-Beispiels, wie wichtig es ist, dass das verwendete Pattern erkennbar (Meyer sagt: dokumentiert) ist – etwas, dem kein agiler Entwickler jemals widersprechen würde. An einer anderen Stelle wird deutlich, dass er das Konzept des Backlogs in Kombination mit schnellem Feedback nicht verstanden hat: In Meyers Welt werden im klassischen Requirements Engineering unnötige Anforderungen vor der Analyse aussortiert, wohingegen seiner Meinung nach im Agilen auf eine Analyse verzichtet wird und unnötige Requirements nach der Implementierung(!) wieder ausgebaut werden. Aus welchem Projekt auch immer er diese Erfahrung zieht: Es war nicht agil, so arbeiten wir nicht. Ein anderer Punkt, den Meyer kritisiert, ist das vermeintliche Verzichten auf Architekturarbeit vor der Implementierung. Auch hier folgt er seinem Prinzip: er beschreibt ein Extrem wo in der Realität Pragmatismus herrscht. Er verwechselt den Verzicht auf Unnötiges mit einem generellen Verzicht und verstrickt sich in der weiteren Argumentation in der selbst geschaffenen Konfusion.

Auch im dritten Kapitel tappt Meyer wieder in die methodische Falle, die er sich im zweiten Kapitel gebaut hat: Er kritisiert ein in seiner Wahrnehmung nach typisches Verhalten von Agilisten und zeigt selbst das gleiche Verhalten: Er argumentiert immer wieder, dass in Büchern und Veröffentlichungen über Software-Engineering niemand behauptete, Big Upfront Anything wäre eine Lösung. Niemand aus der Agilen Community kritisiert Bücher über Software Engineering. Agilität kritisiert den realen Projektalltag. Und der ist ganz häufig Plan-Driven Waterfall mit viel Big Upfront Anything, obwohl das kein Buch so empfiehlt.

Kapitel 4: Agile Prinzipien

Die agilen Prinzipien dekonstruiert Meyer indem er zeigt, dass sie einer allgemeinen Definition von Prinzip nicht genügen. Woher er seine Definition eines Prinzips nimmt, ist nicht referenziert, aber sie ist in seinem Sinne zweckmäßig. Wikipedia beschreibt ein Prinzip als Ursprung bzw. als Gesetzmäßigkeit, die anderen Gesetzmäßigkeiten übergeordnet ist und weißt explizit darauf hin, dass eine Gesetzmäßigkeit im Sinne eines Prinzips auch eine Regel sein kann. Im Folgenden nimmt er die Prinzipien auseinander und zeigt, inwiefern sie seiner Definition eines Prinzips widersprechen. Auch hier lässt er sich wieder auf diesen unsauberen Stil ein, der den Leser schon durch die ersten drei Kapitel begleitete.

Da die agilen Prinzipien seiner Definition nicht genügen, formuliert er eigene, die in organisatorische und technische Prinzipien aufgeteilt sind. In einigen Aspekten treffen Meyers Prinzipien den Kern der agilen Werte sogar besser als die des agilen Manifests, aber im Wesentlichen sind sie als Strohmann-Argumente angelegt, so dass sie in seinem Sinne widerlegt werden können. Hier alle wiederzugeben würde den Rahmen sprengen.

An einer Stelle zitiert Meyer ein Paper aus dem Jahr 1993, in dem gezeigt wird, dass ein großer Teil der Fehler in einer Software auf das Verständnis der Anforderungen zurückzuführen sind. Die agile Lösung für dieses Dilemma stellt schnelles Feedback durch Anwender dar, Meyer favorisiert eine intensivere Analysephase vor dem Projekt. Sein primäres Argument gegen schnelles Feedback durch Customer Collaboration ist, dass die wesentlichen Stakeholder zu viel beschäftigt sind und deshalb weniger fähige als Vertreter entsendet würden.

Später begründet er, dass auch in agilen Organisationen Manager benötigt würden. Gute Gründe dafür hat Jurgen Appelo mit Management 3.0 geliefert und diese sind in der agilen Community auch anerkannt. Meyer referenziert Appelo nicht, sondern schreibt stattdessen „The need for managers remains, of course, because this is how companies work…“ Ich konnte leider nicht herausfinden, wie ein Manager in Meyers Sichtweise definiert ist, bin mir aber sicher, dass es Leute gibt, die diese Aussage widerlegen können.

Erwähnenswert finde ich noch, dass Meyer in Kent Becks Äußerung, ein Architekt würde auch programmieren eine Provokation sieht. Als jemand der einmal Architekt gewesen ist, glaube ich, kein Programmierer würde mich in dieser Rolle ernst nehmen, würde ich nicht hin und wieder selbst Code schreiben.

Gegen Ende des Kapitels lässt sich Meyer darüber aus, dass Scrum als agiles Projektmanagement Framework Änderungen nicht willkommen heißt, wie es das Agile Manifest fordert. Hier verwechselt er die definierte Arbeit im Sprint mit Änderungen im Backlog. Für die Gründe der Unveränderlichkeit von Anforderungen während eines Sprints interessiert er sich nur marginal – immerhin findet er diese Regel akzeptabel.

Während er im Kapitel verteilt relativ viel zu additiver und multiplikativer Komplexität schreibt, beachtet er leider nicht, dass Softwareentwicklung ein komplexes System ist und viele Dinge voneinander abhängen und miteinander wirken. Daher ist sein lineares Vorgehen zur Dekonstruktion der agilen Prinzipien nur von begrenztem Nutzen, wenn es darum geht, Agilität zu untersuchen.

Mittlerweile habe ich die Hälfte des Buches gelesen und kann nur den Kopf schütteln. Warum schreibt jemand wie Meyer, der eigentlich eine Instanz ist, so unreflektiert und unsauber über ein so wichtiges Thema?

Kapitel 5: Agile Rollen

Das Kapitel über die Rollen in agilen Organisationen ist recht kurz.

Meyer beschreibt, dass die agile Community Manager vor allem negativ betrachtet und über Verbote definiert. Steve Jobs benennt er als ein Beispiel für einen Manager, der sich nicht bewerben bräuchte – ich nenne ihn immer als ein Beispiel für einen Product Owner. Diesen beschreibt Meyer dann auch viel zu kurz – er reduziert ihn darauf, Storys zu Beginn eines Sprints auszuwählen und am Ende des Sprints abzunehmen. Diese Aufgaben gehören natürlich dazu, sind aber nur ein Bruchteil dessen, was ein Product Owner leisten muss. Insbesondere ignoriert Meyer komplett die ökonomische Verantwortung eines Product Owners.

Weiter schreibt Meyer über agile Teams, dass sie viele Management-Aufgaben wahrnehmen „…including the critical one of deciding, step after step, what tasks to implement“. Man könnte jetzt den Versuch unternehmen, Meyers Text dahingehend auseinander zu nehmen, dass ein Manager, der sich tatsächlich um einzelne Implementierungsaufgaben kümmern muss, zu wenig Energie in das Big Design Upfront investiert hat. Die Zeit spare ich mir aber. Wenn Meyer nicht zu den Managern gehört, die ihren Entwicklern vertrauen, sind agile Projekte mit ihm nicht möglich.

Spannend wird die Sache, wenn er zum Thema Kunden und Repräsentanten gelangt. Meyer meint, dass relevante Anwender so stark in Organisationen eingebunden sind, dass sie für die Teilnahme an einem Projekt nicht zur Verfügung stehen. Stattdessen würden an ihrer Statt zweitklassige Mitarbeiter entsandt, die man auf Anwenderseite los werden wollte. Abgesehen davon, dass das auch seine Idee der Vorab-Anforderungsaufnahme unmöglich machen würde, halte ich diese These für gewagt – denn sie sagt nichts anderes, als dass das betreffende Projekt für das Management nicht wichtig genug war, um den relevanten Leuten entsprechende Zeit einzuräumen.

Von Scrum Mastern hat Meyer keine gute Meinung. Zum Einen, weil es Zertifizierungsprogramme gibt und zum Anderen, weil Scrum Master nicht an der Entwicklung beteiligt sein sollen. Ersteres ist in meinen Augen für eine Bewertung der Rolle des Scrum Master irrelevant. Zweites kann man durchaus diskutieren – und kommt meistens zu einem Ergebnis, das Meyer vermutlich ablehnen würde, weil es ein typischer Ausspruch seiner so verhassten Consultants ist: Es kommt darauf an. Ich kenne Teams, bei denen es hilfreich ist, als Scrum Master mit zu entwickeln. Und ich kenne Teams, bei denen das extrem behindert hat. Ich selbst hatte als Scrum Master nie Zeit, mit Hand an den Code zu legen, weil ich damit beschäftigt war, mein Team großartig zu machen. Das können in Meyers Welt aber nur Manager, in denen er die besseren Scrum Master sieht. Auch hier denke ich: es kommt darauf an.

Gegen Ende des Kapitels schlägt Meyer endlich etwas versöhnlichere Töne an: „Every project must examine that tradeoff in light of its own circumstances; there is no universal, dogmatic answer.“ Dem kann ich nur zustimmen, genau das ist das, was ich immer aus der agilen Community höre.

Kapitel 6: Management-Praktiken

Auch dieses Kapitel ist kurz – so kurz wie es von der Praxis weit entfernt ist. Meyer bringt hier viel durcheinander. Er verwechselt die Aufgabenliste im Sprint mit dem Backlog: „It is the rule that during a sprint, the task list does not grow.“ – Die Task List darf wachsen, nur die User Storys dürfen sich nicht ändern. Oder er schreibt das Abbrechen des Sprints dem Product Owner zu: „terminating the sprint early — a decision that, as we have seen, is the privilege of the product owner.“ Nun, meines Wissens nach ist das nirgendwo definiert und wird in der Community aufs Heftigste diskutiert.

In Zusammenhang mit der Closed-Window Rule bringt Meyer auch die Änderung am Inhalt des Sprints mit Änderungen am Product Backlog durcheinander. Änderungen sind willkommen, am Product Backlog dürfen jederzeit Änderungen vorgenommen werden. Aber nicht am Inhalt des Sprints.

Bedauerlich finde ich Meyers ablehnende Haltung gegenüber dem Daily Standup. Er bringt die üblichen Argumente wie Zeitzonen bei verteilten Teams, Meeting-Inflation und unterschiedliche Anwesenheiten bei flexiblen Arbeitszeiten. Alles typische Fälle, in denen die Teams mit denen ich bisher gearbeitet habe, Lösungen gefunden haben.

Das Planning Game und Planning Poker beschreibt Meyer ebenfalls anders, als ich es kennengelernt habe und mit meinen Teams praktiziere. Ich kann aber durchaus verstehen, dass insbesondere das Planning Poker nach Meyers Vorlage nicht funktioniert. Hier stimme ich ihm absolut zu.

Es geht weiter im Kapitel mit Iteration Planning, Code Ownership, den Scrum-Meetings und anderen Dingen, die Meyer als Management-Praktiken einstuft. Einiges davon erklärt er falsch (Iteration Planning) oder erkennt nicht an, dass es neben seinem zentralistischen Weltbild durchaus erfolgreiche Projekte gibt, die multiplikative Komplexität mit einem Scrum-of-Scrums beherrschen.

Deprimierend finde ich seinen Standpunkt zur Code Ownership. Als jemand, der lange Zeit in Open Source Projekten mitgearbeitet hat und auch in dem ein oder anderen großen Industrie-Projekt dabei war, weiß ich wie kritisch ein hoher Truck-Faktor – der geht nämlich mit Fürstentümer im Code einher – ist.

Kapitel 7: Technische Praktiken

Das Kapitel funktioniert ähnlich wie Kapitel 6. Meyer stellt etliche Praktiken aus der agilen Community vor – das bedeutet: er beschreibt, wie er sie versteht – und nimmt sie dann auseinander. Das gelingt mal besser und mal schlechter, scheitert aber in der Regel an praktischer Erfahrung in realen agilen Projekten (das behaupte ich hier einfach mal, anders kann ich mir vieles in diesem Buch nicht erklären – wer es widerlegen mag: Kommentare sind offen). Wenn Meyer Refactoring kritisiert mit den Worten „refactored junk is still junk“ dann fehlt mir ehrlich gesagt eine Idee, was ich dazu schreiben könnte.

Im Wesentlichen geht es um Pair Programming, Coding Standard, Continuous Integration, Refactoring und Test Driven Development. Mir fehlen zu einer ernsthaften, kritischen Auseinandersetzung die Studien, die zeigen, dass TDD und Pair Programming die Produktivität erhöhen. Vielleicht hat Meyer die einfach nicht finden können.

Meyers Ton wird versöhnlicher. Zwar ist die Grundstimmung im Buch noch sehr aggressiv, aber es kommen öfter zähneknirschend Zwischentöne, die konstatieren, dass doch nicht alles so schlecht ist – auch wenn Meyer nicht müde wird, zu betonen, dass Design by Contract Unit Tests selbstverständlich überlegen ist.

]]>
http://gerritbeine.com/2015/04/bertrand-meyer-agile-the-good-the-hype-and-the-ugly/feed/ 0
Ulf Brandes, Pascal Gemmer, Holger Koschek & Lydia Schültken: Management Y http://gerritbeine.com/2015/03/ulf-brandes-pascal-gemmer-holger-koschek-lydia-schueltken-management-y/ http://gerritbeine.com/2015/03/ulf-brandes-pascal-gemmer-holger-koschek-lydia-schueltken-management-y/#comments Wed, 04 Mar 2015 20:39:13 +0000 https://gerritbeine.com/2015/03/ulf-brandes-pascal-gemmer-holger-koschek-lydia-schueltken-management-y/ Weiterlesen ]]>
Ulf Brandes, Pascal Gemmer, Holger Koschek & Lydia Schültken: Management Y

Ulf Brandes, Pascal Gemmer, Holger Koschek & Lydia Schültken: Management Y

Allen, die als Nicht-ITler ins Thema Agilität und vor allem Führung im agilen Kontext einsteigen wollen, sei dieses Buch wärmstens empfohlen. Wer – wie ich – schon länger mit diesen Themen unterwegs ist, wird allerdings wenig neues entdecken.

Der Aufbau des Buches erinnerte mich sehr stark an Fearless Change. Zunächst wird im Teil Mehr Menschlichkeit im Management! die grundlegende Motivation für das Buch erklärt. Die von den Autoren vertretenen Ansichten teile ich auch – bis auf die Tatsache, dass Taylor unverdient mal wieder viel zu schlecht wegkommt.

Im zweiten Teil des Buches wird Management Y aus vier Sichten beschrieben: Organisation gemeinsam erleben, Liefern, was gebraucht wird, Menschen ehrlich begeistern und Kunden wirklich verstehen.Der zweite Teil ist eine Runde Sache und für Einsteiger super. Alle vier Blickwinkel werden kompakt beschrieben und moderne Wege gezeigt, sich ihnen zu stellen. Einziges Manko ist, dass bestimmte Modelle sehr stark im Fokus stehen – vielleicht weil sie den Vorlieben der Autoren entsprechen.

Mit insgesamt 24 Pattern ist der dritte Teil sehr hilfreich, wenn man sich in der Welt agiler Praktiken orientieren will. Wer regelmäßig in der Community unterwegs ist, Blogs liest oder schon andere Bücher zum Thema kennt, wird aber nur schwerlich etwas Neues finden.

Der Ausblick am Schluss ist für mich persönlich etwas zu esoterisch. Ich mache zwar regelmäßig Yoga und meditiere auch sehr gerne – aber das passt nicht zu einem Buch, dass das Wort Management im Titel trägt.

Der Titel ist auch das, was ich an dem Buch im Wesentlichen kritisieren muss. Ich bin ein großer Verfechter des Management 3.0 und empfand das Buch von Jurgen Appelo als einen Meilenstein der Management-Literatur. Management Y hat mit Management …wenig zu tun. Es ist eher eine Ideensammlung und ein Startpunkt für Menschen, die sich mit dem Thema Agilität auseinandersetzen wollen. Wer sich mit Führung – oder Management – in agilen Organisationen auseinandersetzen will, kommt nach wie vor an Appelo nicht vorbei.

Mein Fazit: Das Buch ist super. Für mich persönlich war es viel zu flach. Aber ich bin auch nicht die Zielgruppe. Es gibt dennoch vier Sterne bei Goodreads, weil die Zusammenstellung im Buch für Einsteiger richtig Klasse ist – und die sind mit Sicherheit auch die Zielgruppe :-)

]]>
http://gerritbeine.com/2015/03/ulf-brandes-pascal-gemmer-holger-koschek-lydia-schueltken-management-y/feed/ 0
Apple SuperDrive am USB-Hub http://gerritbeine.com/2014/12/apple-superdrive-am-usb-hub/ http://gerritbeine.com/2014/12/apple-superdrive-am-usb-hub/#comments Sat, 20 Dec 2014 19:43:51 +0000 https://gerritbeine.com/?p=163 Weiterlesen ]]>

Apple empfiehlt das SuperDrive nur an USB-Ports direkt am Mac zu betreiben.
Nun stellt selbst das MacBook Pro leider nur zwei USB-Ports zur Verfügung, was das Ganze ziemlich lästig macht.

Hängt man das Laufwerk an einen USB-Hub, erhält man die lapidare Meldung, dass dieses Gerät mehr Strom benötigt. Dabei gibt es durchaus USB-Hubs, die genügend Strom für das SuperDrive bereitstellen.

Damit OS X das SuperDrive an so einem USB-Hub akzeptiert, muss man den Kernel wie folgt motivieren.

Als root muss man die Boot-Parameter editieren:

vi /Library/Preferences/SystemConfiguration/com.apple.Boot.plist

In der Datei ergänz man dann mbasd=1, so dass sie folgendermaßen ausschaut:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Kernel Flags</key>
        <string>mbasd=1</string>
</dict>
</plist>

Jetzt noch ein Neustart, und das SuperDrive läuft am USB-Hub.

Achtung: Wenn der USB-Hub tatsächlich zu wenig Strom zur Verfügung stellt, kann es zu Datenfehlern kommen. Ein USB-Hub, der auf zwei Power-Ports ausreichend Strom liefert, ist der DUB-H7 von D-Link.

Referenz: How to Run a SuperDrive on a Targus Hub

]]>
http://gerritbeine.com/2014/12/apple-superdrive-am-usb-hub/feed/ 0