Diskussions-Aikido – Diskussionen sind wie Kampfkunst...

Diskussionen gewinnen? Oder das Ziel erreichen?

Als guter und geübter Rhetoriker mag man in der Lage sein, viele Diskussionen nominell für sich zu entscheiden. Wenn der „Gegner“, der am Ende der Diskussion grollend klein beigibt aber gerade der Mensch ist, mit dem ich im Sinne der Sache zusammen arbeiten will – oder eventuell sogar „muss“ –, dann habe ich möglicherweise den Kampf gewonnen, aber das gesamte Vorhaben hat einen Verlust erlitten.

Der Klügere gibt so lange nach,…

… bis er der Dumme ist, heißt es von Zeit zu Zeit. Alleine der harmoniesuchende Kurs führt auch nur in wenigen Fällen zum Ziel.

Friedliche Kampfkunst als Muster?

Vor einer ähnlichen Situation stand der Entwickler des Aikido, als er diese Kampfkunst aus den sehr viel brutaleren Kampfkünsten die er vorher unterrichtet hatte entwickelte.
Er entwickelte eine Kampfkunst, die die Energie des Angreifers nicht nur gegen ihn selbst wendet, sondern die angreifende Partei so behutsam abwehrt, dass hinterher ein friedliches Miteinander realistisch bleibt.

Aikido in der Diskussion

Wie sich Aikido und Rhetorik nach unserer Sicht miteinander verbinden lassen haben Björn Klug und ich auf der OOP2015 in einem Vortrag zusammengefasst...

Diskussionen sind wie Kampfkunst

Der Vortrag.

Bis bald …
  Michael Mahlberg

Die Angst des Software-Entwicklers vor der Kommandozeile... ?

Haben Software-Entwickler denn Angst vor der Kommandozeile?

„Angst“ ist natürlich ein starkes Wort, aber es fällt mir schwer eine andere Interpretation für das Verhalten zu finden, wenn Entwickler für die Versionsverwaltung lieber Subversion als git verwendeten, weil es für git keine gut funktionierende Explorer-Integration (wie z. B. TortoiseSVN) gab¹ und sie deshalb mit der Kommandozeile arbeiten müssten. Oder, dass eher Excel eingesetzt wird als SQLite um Tabellen auszuwerten, weil man für SQLite ja „immer die Kommandozeile braucht“. Oder, dass zwar die IDE-Funktion zum Erzeugen des auslieferbaren Produktes genutzt wird, aber nicht der Aufruf von make, rake, ant, maven, gradle etc. von der Kommandozeile.

Die Beispiele ließen sich lange weiterführen, aber die grundlegende Frage bleibt: Warum schrecken so viele Entwickler vor der Nutzung der Kommandozeile zurück?

Ist das Werkzeug des Software-Entwicklers nicht „Text“?

Tagein, tagaus schreiben Software-Entwickler Programmcode¹. Zwar bei weitem nicht so viel, wie viele Nicht-Programmierer denken – nach verschiedenen Studien liegt das Verhältnis von Lesen zu Schreiben bei 7 zu 1 oder noch höher –, aber dennoch gehört das Schreiben von Worten in einer Sprache, die ein Programm interpretieren und bearbeiten kann, zum Alltag eines jeden Softwareentwicklers. Und nicht nur das, die meisten Entwickler beherrschen darüber hinaus noch eine ganze Reihe von solchen Sprachen, die sie benötigen um ihr Tagewerk zu vollbringen.

Woher also kommt der Widerstand gegenüber der Kommandozeile? Ist es die schlechte Benutzbarkeit der jeweiligen Kommandozeilen der Betriebssysteme? Die schlechte Dokumentation? Die Tatsache, dass die jeweilige Domäne schon komplex genug ist, und die Vereinfachung durch eine grafische Oberfläche dringend benötigt wird?

Ich habe leider wirklich keine Antwort und würde mich über Hinweise auf Erklärungsansätze – z. B. in den Kommentaren, aber auch gerne per Mail oder Twitter freuen.

Bis demnächst
  Michael Mahlberg

---

Fußnote

¹ Ob es gut ist, dass es mittlerweile mit TortoiseGit ein Tool gibt, dass es ermöglicht, mit git nahezu genau so zu arbeiten, wie früher mit Subversion ist eine andere Frage

Quasi-Fußnote

² Strenggenommmen manipulieren Softwareentwickler abstrakte Syntax-Bäume (AST), indem sie deren textuelle Repräsentation gestalten. Die heute noch übliche Weise, die textuellen Repräsentationen zu manipulieren, ist das Erfassen des Textes über die üblichen Methoden der Texteingabe (Tastatur, Sprache etc.). Hierbei wird die textuelle Darstellung jedes mal neu erzeugt, wobei heute kontext-erkennende Entwicklungsumgebungen bereits viele Vorschläge für die Vervollständigung der einzelnen Worte machen. Bereits 2003 allerdings stellte James Gosling eine Alternative zu dieser Herangehensweise vor: Eine Entwicklungsumgebung, die direkt den AST manipuliert und die textuelle Repräsentation nur noch für den menschlichen Benutzer generiert. Leider war „Jackpot“, so der Name dieses Projekts, kein großer Erfolg beschieden und heutzutage ist es schwer überhaupt noch Information über dieses Projekt zu finden.

Ein anderes System, das erfolgreich viele Jahre auf Texteingaben zur Softwareentwicklung – außer für Werte – verzichtete, war das von James Martin Associates (später von Texas Instruments gekauft) entwickelte Information Enginering Facility (IEF), aus dem heute das Tool CA Gen geworden ist, welches sich mittlerweise ebenfalls vom Gedanken der reinen Modellierung der Syntaxbäume entfernt hat.

Insgesamt scheint also die unsichtbare Hand des Marktes doch ein großes Interesse daran zu haben, dass Entwickler weiterhin in aktiv Text schreiben um Programme zu erstellen und maximal durch Werkzeuge wie die automatische Vervollständigung von Schlüsselworten unterstützt werden.

Unpopuläre Thesen 2013-09-25: Scrum und Kanban sorgen nicht für gute Softwareentwicklung

Scrum an sich macht niemanden zu einem besseren Software-Entwickler!
Und (Software-)Kanban macht als solches ebenfalls niemanden zu einem besseren Software-Entwickler (und ist – nebenbei bemerkt – auch kein Ersatz für Scrum! )

Und – nur um es noch mal deutlich zu machen – Scrum ist kein Synonym für "Agil" oder "Agile". Unter den Agilen Methoden sorgt zum Beispiel eXtreme Programming (XP) meiner Ansicht nach sehr wohl für gute Softwareentwicklung, solange man es ausreichend ernst nimmt.
Aber zurück zu Scrum. Das Schöne an Scrum ist ja gerade, dass es so universell einsetzbar ist! Um die deutsche Übersetzung des Scrum-Guide zu zitieren: „Scrum ist ein Framework, das die Entwicklung komplexer Produkte unterstützt.“ In diesem Satz steht nichts von Software – und wenn man den Scrum-Guide nach „Programm“ oder „Software“ durchsucht, wird man ebenfalls nicht fündig – egal, ob in der englischen Ausgabe vom Juli 2013 oder in der deutschen Übersetzung zum Stand 2011.

Eines der bekannteren Beispiele für die Anwendung von Scrum ausserhalb der Software-Entwicklung ist die Wartung von Formel-1 Wagen mit Scrum^[1] – ich bin sicher, dass gerade hier von allen Team-Mitgliedern erwartet wird, dass sie ihr Handwerkszeug perfekt beherrschen.

Die Dinge, die dabei helfen, bessere Software-Entwickler zu werden, sind andere: Wissen über Entwurfsmuster (siehe auch: Wikipedia), Kenntnis von Architektur und Entwurfsprinzipien (z. B. SOLID (siehe auch: Wikipedia) und Co.), Einsatz von testgetriebenem Design, Programmieren in Paaren, kontinuierliche Integration und letztendlich – auch wenn aus einem gewissen Blickwinkel die konkrete Programmiersprache nicht so entscheidend sein mag – die Beherrschung der für die Umsetzung notwendigen Sprachen, Bibliotheken und Frameworks.
Wenn diese Elemente erfüllt sind, dann helfen Prozesse wie Scrum und Prozessverbesserungsmethoden wie die Kanban Methode (oder als englische Kurzübersicht) dabei, wirklich das zu entwickeln, was einen Wert für den Kunden darstellt, und sich nicht in Technikalitäten zu verlaufen, in der Analyse stecken zu bleiben oder in eine der vielen anderen Fallen des Projektmanagements zu laufen.
Analog zum alten Rezept für einen guten Grog („Rum muss, Zucker kann, Wasser braucht nicht“) an dieser Stelle daher mein Plädoyer:

• Technische Expertise: Notwendig, aber nicht hinreichend
• Kanban Methode: Sollte, aber nicht als einziges
• Scrum: Kann, aber nicht als einziges

Bis demnächst
  Michael Mahlberg

---

[1] Die „Scrum in der Formel-1“ Geschichte hält sich seit Jahren, ich habe aber leider keine Primärquellen finden können

Polyglotte Programmierung ist Alltag

Von Zeit zu Zeit wird die Idee, das man deutlich mehr als eine Programmiersprache beherrschen sollte unter der Bezeichnung "Polyglotte Programmierung" – also "vielsprachige Programmierung" – als progressive Erkenntnis oder auch als Wettbewerbsvorteil proklamiert. Mich verblüfft das immer wieder – ebenso wie die ablehnenden Reaktionen einiger Entwickler zu dieser Idee.
Schließlich leben wir schon lange in einer Welt, in der es für Entwickler unverzichtbar und meines Erachtens auch Alltag ist, mehr als eine Sprache zu benutzen.

In den meisten Fällen, die über triviale "Hallo, Welt!" Beispiele hinaus gehen, kommen heute fast immer mehre Sprachen (seien es Programmier- oder Beschreibungssprachen) zum Einsatz. Gucken wir uns nur mal einige wenige Beispiele an:

• .Net, Desktop-Anwendung

  • C# (oder VB.Net oder eine andere Sprache der Wahl) für die Logik
  • SQL für die verwalteten Daten

• PHP, Web-Anwendung

  • PHP - für die Implementierung der Logik,
  • HTML - für die logische Gestaltung der Benutzungsschnittstelle
  • CSS - für die optische Gestaltung der Benutzungsschnittstelle
  • SQL - für die verwalteten Daten
  • Wahlweise: Shell-Syntax - mindestens zum starten und stoppen des Servers, kopieren von Dateien etc. (kann ggf. auch mit einem grafischen Interface gemacht werden)
    • Wenn es etwas mehr sein darf
    • Java-Script - für Interaktionen im Oberflächenlayer
    • die jeweilige Sprache (oft XML-basiert) für die Konfiguration des Build-Servers
    • Config-Sprache des Servers (e.g. apache-conf)

• Ruby, Web-Anwendung, Stack von ~2012

  • Ruby - für die Logik
  • haml - für die logische Gestaltung der Oberfläche
  • Sass - für die optische Gestaltung der Oberfläche
  • Coffeescript - für die 'clientseitige' Logik
  • yaml - für diverse Einstellungen, nicht zuletzt die Unterscheidung zwischen Test- und Realbetrieb
  • RSpec / Cucumber - für die lokalen Tests
  • Capybara DSL - für remote Tests
  • SQL - für die verwalteten Daten

• Java, Web-Anwendung, Minimalistisch

  • Java - für die Logik
  • HTML - für die logische Gestaltung der Benutzungsschnittstelle
  • CSS - für die optische Gestaltung der Benutzungsschnittstelle
  • JSP-taglibs - für die dynamischen Teile der Oberfläche
  • SQL - für die verwalteten Daten
  • XML - für die Buildskripte
  • Property-File Syntax -
  • Wenn es etwas mehr sein darf
    • Java-Script für Interaktionen im Oberflächenlayer
    • die jeweilige Sprache (oft XML-basiert) für die Konfiguration des Build-Servers
    • Config-Sprache des Servers (e.g. apache-conf)

Und ähnlich sieht es bei allen weiteren mir bekannten Umgebungen aus, wenn wir von professioneller Softwareentwicklung (Nein, Excel-Markos zähle ich nur selten dazu, manchmal aber schon) sprechen.

Also sollte die Frage heute weniger denn je lauten "Was ist denn unsere Standardsprache" sondern viel mehr "Welche Sprache passt am besten zum Problem".

Bis demnächst
  Michael Mahlberg

Es gibt keine Server für kontinuierliche Integration (oder auch "CI-Server" ist ein Oxymoron)

Sätze wie

• „Der gesamte Vorgang wird automatisch ausgelöst durch Einchecken in die Versionsverwaltung.“[1]
• „<x> is an open-source continuous integration server with...“ [2]
• „[…] Kontinuierliche Integration steigert die Effizienz durch Automatisierung […]“[3]

zeigen mir immer wieder die immense Macht der semantischen Diffusion.

Es gibt keine CI-Server – selbst Szenarien, in denen der Server am Ende eines fehlerhaften Buildlaufes das gelieferte Changeset zurückweist, stellen nicht sicher, dass die Teilergebnisse wirklich integriert werden.

Was oft als CI-Server beschrieben wird, sind Build-Server, integriert wird hier nichts. Buildserver gibt es durchaus auch in meinem Vokabular, kontinuierliche Integration aber, so wie ich sie das erste Mal 2001 bei Kent Beck beschrieben gesehen habe, ist eine Arbeitsweise, bei der alle Beteiligten sicherstellen, dass ihre letzten fertiggestellten Arbeitsergebnisse in das Gesamtprodukt integriert sind. Dorthin zu kommen, gibt es viele Wege, aber keiner davon ist durch einen Server zu automatisieren.

Auf abstraktem Niveau ist das Vorgehen immer wieder das Gleiche:

• An den eigenen Arbeitsergebnissen arbeiten
  • Sicherstellen, dass die aktuelle Version des Produktes funktioniert
  • Meine eigenen Arbeitsergebnisse integrieren
  • Sicherstellen, dass die jetzt aktuelle Version des Produktes funktioniert
  • wenn sie nicht funktioniert, wieder einen funktionierenden Stand herstellen
    • Wenn dies ebenfalls nicht funktioniert, dann das ganze Team zusammenrufen, um wieder einen funktionierenden Stand herzustellen
  • Die eigenen Arbeitsergebnisse modifizieren, bis berechtigter Grund zu der Annahme besteht, dass eine Integration jetzt erfolgreich sein kann
• Das Ganze so lange wiederholen, bis die eigenen Arbeitsergebnisse komplett in das Gesamtprodukt integriert sind, bevor neue Halbfertigteile produziert werden

In der Praxis gibt es sehr viele valide Ausprägungen dieses Vorgehens, die unter anderem auch die Nutzung von Buildservern umfassen können. Sie alle aber scheinen zunächst einen erheblichen Nachteil zu haben, der meiner Meinung nach Ursache dafür ist, dass so oft keine permanente Integration stattfindet, sondern statt dessen das fehlen der Integrationsarbeit hinter dem Feigenblatt des „Integrations-Servers“ versteckt wird.
Dieser Nachteil ist, dass in dieser Welt nicht mehrere „Änderungen“ zur gleichen Zeit integriert werden können. Und da die Integration nach diesem Modell ja erst abgeschlossen ist, wenn das System nachweislich funktioniert, steht und fällt die Umsetzbarkeit dieses Vorgehens mit der Zeit, die benötigt wird, um das Funktionieren des Gesamtsystems nachzuweisen.

An dieser Stelle sind zwei grundsätzlich unterschiedliche Herangehensweisen üblich. Eine Lösung für die Herausforderung kann sein, die Zeit zu minimieren, die benötigt wird, um das Funktionieren des Gesamtsystems nachzuweisen. Das ist der „harte” Weg, der zunächst deutlich schwieriger scheint und es erforderlich macht, sich mit allen Problemen auseinanderzusetzen, sobald sie auftauchen. Eine andere – scheinbare – Lösung, dieser Herausforderung zu begegnen, ist die Entkopplung der Integration von der Weiterführung der Arbeiten. Hier haben dann automatisierte Integrationstests und die sogenannten „CI-Server” ihren großen Auftritt.

Das Vorgehen hier ist also:

• An den eigenen Arbeitsergebnissen arbeiten
• Die eigenen Arbeitsergebnisse zur Verifikation an den Integrationsserver abgeben (möglicherweise von mehreren Teams zur Zeit)
• An neuen eigenen Arbeitsergebnissen arbeiten
  hier haben wir je nach Anzahl der Entwickler mehr oder weniger nicht-integrierten Code
• Falls (später) ein Fehler vom Server gemeldet wird, versuchen diesen zu beseitigen

Das ist natürlich viel einfacher, es gibt keine Schleifen, die man drehen muss, keine Synchronisation mit anderen Integrationswilligen, keine Wartezeiten während der Integration.

Das große Problem bei diesem Vorgehen ist nur, dass nicht verifizierte Teilfertigprodukte entstehen – um so mehr, je häufiger die Entwickler ihre Teilergebnisse an den Server überantworten.

Es gibt zwar schon geraume Zeit Ansätze dieses Thema auch technisch zu adressieren – z. B. mit gerrit und darauf aufsetzenden Workflows – aber hier dienen die Werkzeuge erfreulicherweise der Unterstützung der Menschen, und es wird nicht unterstellt, dass sie die Integration durchführen.

Eigentlich lässt sich ganz leicht feststellen, ob es in einer Umgebung eine permanente Integration gibt oder nicht – immer dann, wenn es fehlerhafte Builds gibt, scheint die Integration weder permanent noch kontinuierlich zu sein.
Schließlich ist in der „roten“ Zeit mindestens der für den Fehler verantwortliche Teil eben gerade nicht integriert. Und wenn die Build-Zeit lang genug ist, dann ist in der Zeit Neues entstanden, was ebenfalls nicht integriert ist. Und während die Fehler behoben werden steigt die Menge nicht integrierter Teilprodukte, wenn die anderen Projektmitglieder weiter arbeiten.
All dies passiert nicht, wenn tatsächlich nach dem oben beschriebenen Muster permanent integriert wird!

Wer also permanente Integration (continuous integration) will, muss sich meiner Ansicht nach auf Prozessebene damit auseinandersetzen und wir alle sollte Build-Server auch Build-Server nennen und den Begriff CI-Server meiden, solange diese keine wirkliche Integration betreiben können.

Bis zum nächsten Mal
  Michael Mahlberg

Quellen aus der Einleitung:

• [1] aus dem deutschen Wikipedia Eintrag
• [2] von der Jenkins Startseite
• [3] aus einem Industrieartikel

Und gerade noch im Netz gefunden: Bereits vor 2006 hat Jim Shore seine Einstellung zu Continuous Integration veröffentlich, und hatte insbesondere seine eigene Meinung zu CruiseControl (einem speziellen Build-Server)

Unpopuläre Thesen 2013-09-03: "Agil" sollte beweglich bleiben – und Lean sollte schlank bleiben

Agile Software-Entwicklung hätte fast den Namen Adaptive Software-Entwicklung bekommen - vielleicht wäre dann vieles gar nicht erst so Missverstanden worden. Vielleicht aber auch doch - semantische Diffusion ist stark in unserer Branche.

Sehr schön in diesem Zusammenhang: Die Rückbesinnung einiger Twitterer auf ein paar wesentliche Punkte des agilen Manifests:

sie haben gesagt "[…] indem wir es tun und anderen dabei helfen es zu tun […]" und nicht "[…] indem wir anderen erzählen, wie sie es tun sollten, ohne es selbst zu tun […]" -- Tweet von Torbjörn Gyllebring, 2013-08-29

Zur Erinnerung: sie sagten "Wir erschließen bessere Wege, Software zu entwickeln" und nicht "wir haben bessere Wege erschlossen[…]" -- Tweet von Steve Rogalsky, 2013-08-29

In diesem Sinne, bis bald
  _MM_

Wir haben Baseball ausprobiert und es hat nicht funktioniert!

Eine Allegorie? Sarkasmus? Humorvolle Persiflage? Entscheiden sie selbst.

Von Ron Jeffries, Original unter: http://xprogramming.com/articles/jatbaseball/

Die fanatischen Fürsprecher des Baseballs erzählen uns, es sei ein unglaublich tolles Spiel, das sowohl den Spielern als auch den Zuschauern viel Spaß macht. Es ist ganz klar zu erkennen, dass die Fürsprecher entweder dumm oder böse sind, denn wir haben Baseball ausprobiert und es hat nicht funktioniert.

Es fängt schon damit an, dass die Anforderungen um das Spiel zu spielen unsinnig sind - sie lassen sich einfach nicht skalieren. Es werden mindestens neun Spieler pro Seite verlangt. Das ist unglaublich ineffizient. Die Minimalanzahl an Spielern ist ganz klar vier: drei im Spiel und einer am Abschlag. So haben wir auch gespielt vier Spieler pro Seite.

Mit nur vier Spielern brauchten wir auch nicht all diese Male (die Namensgebenden 'bases'), was ein weiteres Indiz für die offensichtliche Ineffizienz und die mangelnde Skalierbarkeit ist. Wir haben deshalb nur ein einziges Mal benutz - die 'Home-Base'. Wenn eine schlagende Person einen Ball schlägt, dann läuft er um ein Quadrat - mehr dazu gleich - um dann zurück zum einzigen Mal zu kommen. Zuerst ließen wir den Läufer um das komplette 90 Fuß (ca. 27 Meter) Quadrat laufen, wie es die Baseball-Befürworter empfehlen. Aber aus irgendeinem Grund haben die Baseballleute nicht bemerkt, dass 360 Fuß (ca. 110 Meter) bei den meisten Treffen viel zu weit ist, um sie rechtzeitig zurück zu legen. Bei uns hat es nie jemand geschafft, die ganze Strecke zu laufen ohne aus dem Spiel genommen zu werden. Wir haben festgestellt, dass ein Kreis mit einem Durchmesser von exakt 28,64 Fuß (8,73 Meter) nahezu ideal ist. (Der Kreis, mit seinem idealen Verhältnis von von Fläche zu Umfang, ist auch viel effizienter als das von den Baseballern vorgeschlagene Quadrat.)

Die Ausrüstung, die die Baseball-Leute "verlangen" ist einfach lächerlich, anachronistisch, diskriminierend und gemein. Als erstes wird verlangt, das der "Baseball" mit Pferdeleder bedeckt ist.Das ist gleichzeitig brutal gegenüber den Pferden und diskriminierend gegenüber den traditionellen Lieferanten von Ball-Aussenmaterial, Schweinen und Kühen. Vor diesem Hintergrund haben wir andere Bälle benutzt. Wir haben einen Ball aus un-umhülltem Garn ausprobiert, aber die permanent abnehmend Größe dieser Bälle mache das Spiel schwierig, besonders in den späteren Runden. Golfbälle flogen viel zu weit und waren schwer zu fangen. Eines unserer Teams versuchte es mit den Köpfen von Puppen, die sie von Ihren Schwestern geborgt hatten, aber das führte zu Problemen zuhause. Wie die Befürworter von Baseball ein Spiel unterstützen können, das zu solchen Problemen führt ist uns unverständlich.

Am Ende haben wir uns für Wollsocken entschieden - mit Altpapier gestopft und verknotet. Diese waren einfach zu fangen, flogen nicht zu weit und das herabhängende Ende des Knotens machte es leicht, sie wieder zu werfen.

Die sogenannten "Bats" (Bat kann im Englischen sowohl Fledermaus als auch Schläger bedeuten) sind auch eine schlechte Idee. Zuerst mal haben sie überhaupt keine Ähnlichkeit mit den pelzigen Insektenjägern der Nachthimmel. Die daraus entstandene Verwirrung über die Namensgebung hat viele Spiele verzögert. Zudem sind "baseball-bats" (wir mussten zu vollqualifizierten Namen übergehen) teuer und schwer herzustellen. Wie haben versucht alle Schlagleute das nutzen zu lassen, was sie wollten, aber das machte es sehr schwierig Statistiken zu führen und die scheinen nach Aussagen der Befürworter eine weitere Schlüsselkomponente von Baseball zu sein. Am Ende haben wir und darauf zurückgezogen, Äste zu nutzen, die um das Feld herum zu finden waren. Pinien funktioniert am besten, weil die Äste leicht von den Bäumen zu brechen sind. Und da die Hände vom Pinien-Harz klebrig werden, wird es leichter die Socke zu fangen, wenn man auf dem Feld ist.

Wo wir gerade beim Feld sind: Ein weiteres Problem, dass die Baseball-Freunde nicht vernünftig adressiert haben ist die Tatsache, dass mit einer Person werfend, einem Fänger und nur zweien auf dem Feld, der "Ball" zu oft dorthin geschlagen wird, wo kein Feldspieler ist, was zu viel zu viel Gelaufe und zu Spielen führt, die viel zu lang sind und viel zu hohe Ergebnisse haben. Letztendlich haben wir herausgefunden – ohne das wir nachvollziehen können, warum die ursprünglichen Baseball-Leute das nicht gesehen haben – das es fürchterlich ineffizient ist, nur einen Spieler als Fänger einzusetzen. Wenn die Astperson (Der Begriff "Batter" ist sowohl mehrdeutig als auch unangebracht durch die Änderungen an der Ausrüstung, die wir einführen mussten um das Spiel überhaupt nutzbar zu machen) einen Wurf verfehlt, dann nimmt er einfach selber die Socke und wirft sie der werfenden Person wieder zu. Auf diese Weise können alle vier Defensivspieler auf dem Feld bleiben, was einem sehr viel effizienteren Ressourceneinsatz entspricht - ein weiterer Beweis dafür, das Baseball nicht skalierbar ist.

Der Punkt, der der gesamten Idee von Baseball aber den Todesstoß versetzt ist dies: Selbst mit all diesen Verbesserungen macht das Spiel überhaupt keinen Spaß!

Wir haben Baseball ausprobiert und es hat nicht funktioniert!

Übersetzung Michael Mahlberg mit freundlicher Genehmigung des Autors wartet auf Genehmigung des Autors

Translation Michael Mahlberg with author's permission still waiting for permission from the author

"Selbstorganisierende" Gruppen und De-Motivation...

... es ist für mich immer wieder erstaunlich, wie wenig selbst erfahrene Coaches realisieren, dass Commitments nur funktionieren, wenn sie zweiseitig sind (Beispiel: "Ich finde <X> sollte <Y>" bedeutet erst dann, dass <X> dass auch so sieht, wenn er zustimmt – nicht, wenn er nicht widerspricht) und das man das Engagement massiv untergräbt, wenn man Micromanagement betreibt ...

Auf der anderen Seite ist natürlich das Problem da, dass selbstorganisierende Gruppen, wenn man sich zu weit zurück zieht, sich weit vom ursprünglichen Zweck entfernen - die Herausforderung ist hier, dass passende Gleichgewicht zu finden.

Daher: Notiz an mich selbst: Micromanagement demotiviert immer und direkte Kommunikation ist durch nichts zu ersetzen!
Nicht, dass ich das nicht schon lange wüsste und immer wieder predige, aber man kann es einfach nicht oft genug wiederholen

Cheers
  Michael

Kontaktanfragen auf Xing, ...

... sind ja eine schöne Sache, wenn sie von Leuten kommen, die man kennt.
Aber wie antwortet man auf all die Kontaktanfragen von Leuten, die meinen "Wir haben laut profil die gleichen Interessen, wir sollten Xing-Kontakte sein...

Das hängt sicher von dem jeweiligen Nutzungsprofil ab – mein Nutzungsprofil stammt noch aus Zeiten des openBC und dementsprechend ist für mich der Stellenwert des 'Kontaktes' bei Xing erheblich höher, als der des 'Freundes' bei Facebook.

Und für Diskussionen auf Xing muss man ja nicht in der gegenseitigen Kontaktliste stehen.

Hier meine Standardantwort auf Xing-Anfragen von Leuten, die über Profilähnlichkeiten, gemeinsame Gruppenzugehörigkeit oder ähnliche Dinge zur Kontaktanfrage kommen - zum freien kopieren und modifizieren.

Sehr geehrte<....>

vielen Dank für Ihre freundliche Kontaktanfrage.

Meine Nutzung von Xing geht auf Zeiten zurück, in denen Xing noch OpenBC hieß und aus dieser Zeit stammt auch noch mein Regularium für die Kontakteliste - in meinen Xing-Kontakten befinden sich nur Leute, mit denen mich eine konkrete, bereits erfolgte Zusammenarbeit (auch virtuell und für kurze Zeit) oder eine persönliche Bekanntschaft aus der physischen Welt verbindet. 

Ich habe Ihre Kontaktinformationen unter "gemerkte Personen" hinterlegt und werde gerne auf Sie zurückkommen, wenn ich einen konkretes, passendes Thema habe.

Gerne können Sie mich natürlich weiterhin ganz normal zu konkreten Themen kontaktieren - meine Xing-Knfiguration erlaubt es auch Nicht-Kontakten mir ganz normale Nachrichten zu schicken.

Mt freundlichen Grüßen

Selbstmarketing: 4-, setzen

Bin gerade beim suchen nach Promotions-Material über die Flyer gestolpert, die ich Mitte letzten Jahres mal entwickelt habe um Leuten, die nicht "aus der Branche" sind erläutern zu können, was ich eigentlich mach und an welchen Stellen sie durch die Dienstleistungen meines Unternehmens besser werden könnten.

Hat bis heute noch keiner heruntergeladen... 

Ach ja: Ich habe sie ja auch nirgendwo veröffentlicht... Wie mein Patenkind schreiben würde: (facepalm) 

Im Sinne von "Vorratshaltung ist Verschwendung" eine wirklich unglaubliche Nachlässigkeit, denn wenn sie niemand zu Gesicht bekommen kann sind sie irgendwann überholt (jetzt noch nicht ;-) ) und dann war der Aufwand wirklich Verschwendung. So beläuft sich der Schaden nur auf 10 Monate "Nicht-Nutzung des Produktes", durch die fehlende Veröffentlichung.

Auch wenn noch zwei  Flyer fehlen, hier schon mal – zumindest geblogged – die fertigen:

Inhalt	Datei
Überblick	Paketueberblick-2012-07.pdf
Aufsetzen von Projekten	ProjectJumpstart2012-07.pdf
Einschätzung der Prozesse	AgilityAssessment-2012-07.pdf
Coach the Coach	fehlt
Second Opinion	fehlt

Multitasking - Weniger tun um mehr zu schaffen

Hier die wichtigsten Links zu dem Vortrag zum Thema "Multitasking - weniger tun um mehr zu schaffen, den ich am 21.02. im Startplatz  gehalten habe.

Die Folien selber sind für kurze Zeit unter http://www.michaelmahlberg.de/WenigerTunUmMehrZuSchaffen.pdf zu bekommen.

Nebenbei: Wer mehr zu Lean und Kanban für Wissensarbeit in Unternehmen wissen möchte, kann auf der Kanbankonferenz im Startplatz am 19.04.2013 viel dazu erfahren - jetzt aber zu den angekündigten Links:

Die Idee zur Simulation mit ausführlicher Erläuterung ist auf der Website von Henrik Kniberg zu zu finden.

Die Publikationen zu Little's Law sind inzwischen sehr Umfangreich - eine der interessantesten Darstellungen dazu ist für mich die englische Präsentation von Daniel Vacanti von der LCKE 2012.

Auf Deutsch beschreibt natürlich der Wikipedia-Eintrag zu Littles Gesetz dessen Grundlagen, aber leider sehr kurz.

Auch für Personal Kanban ist die wichtigste Website derzeit nur auf Englisch verfügbar: http://www.personalkanban.com/pk/, aber das Buch zu Personal Kanban ist mittlerweile auch auf Deutsch verfügbar.

Die Pomodoro-Technik allerdings ist auf der englischen Website meiner Ansicht nach inzwischen viel zu aufgeblasen, so dass hier eher der deutsche Wikipedia-Eintrag eine hilfreiche Quelle ist - von der englischen Website nutze ich selber nur noch von Zeit zu Zeit das Cheat-Sheet, das auf einer Seite alles wesentliche zu Pomodoro-Technik zusammenfasst.

Bei weiteren Fragen: Einfach eine kurze Mail an mich schicken, oder es hier in den Kommentaren vermerken.


Cheers
  Michael

P.S.: Einen sehr spannenden Beitrag zu genau diesem Thema hat mir Dorthe von Smartklick Solutions noch geschickt: Auch in Wissenschaftssendungen im ZDF hat man eine klare Meinung zur Effektivität von Multitasking - ab ca. Minute 25 wird in dieser Folge von neo darauf eingegangen. Man beachte besonders die Aussagen ab39:59 und 43:32... Vielen Dank für diesen Hinweis, Dorthe!

Gedanken zu Verträgen in agilen Projekten

Weil es immer wieder Thema ist - ein paar Überlegungen zur Gestaltung von Verträgen für "Agilisten".

Weder Dienstverträge noch Werksverträge scheinen das passende Modell für die Gestaltung von Verträgen zu sein, wenn es um agile Softwareentwicklung geht.

Obwohl es mittlerweile viele Informationen zu diesem Thema gibt – einen Einstieg in das Material geben die Links am Ende des Beitrags –, finde ich ein paar konkretere, direkt umsetzbare Ideen notwendig.

Normale Vertragsmodelle

Das deutsche Recht unterscheidet in diesem Bereich im Wesentlichen zwischen zwei Vertragsmodellen und in diesem Raum bewegen wir uns größtenteils, solange wir uns unter "fremden Dritten" bewegen.

Dienstverträge

Dienstverträge – insbesondere unter der offiziellen Überschrift "Beratung" – haben einen besonderen Charme für den Auftragnehmer: Das einzige was wirklich einklagbar ist, ist die Zeit, die der Auftragnehmer für den Auftraggeber arbeitet. Bestimmte Resultate oder Eigenschaften der Arbeitsergebnisse sind hier nicht wirklich erstreitbar.

Werkverträge

Werkverträge auf der anderen Seite sind scheinbar sehr von Vorteil für den Auftraggeber, da hier gerade die Resultate und Eigenschaften einklagbar sind, die vertraglich festgelegt wurden – unabhängig davon wie lange der Dienstleister tatsächlich braucht. Das Problem in der Software-Entwicklung ist, dass eine vollständige, "korrekte" Spezifikation zu schreiben (zumindest aus mathematischer Sicht) exakt so aufwändig ist, wie das schreiben der Software selber und somit die Erstellung des Vertragswerks unangemessen teuer wird.

Diese beiden Varianten fallen also schon mal aus - zumindest als Einzellösungen.

Alternative Verträge für agile Projekte

Aber wie sieht es mit einer Kombination der Lösungen aus?
Wenn wir im Auge behalten wollen, dass wir uns im deutschen Vertragsraum aufhalten und trotzdem einfache Verträge schließen wollen, dann lassen sich durch eine Trennung der Bezahlung der Zeit einerseits und der Inhalte und Qualität andererseits die Verträge sehr stark vereinfachen.

Die meiner Ansicht nach sinnvollste Lösung hat Henrik Klagges in seinem aktuellen Vortrag [4] sehr schön umrissen:

Modell “Proviant und Prämie”
- Der Lieferant bekommt einen niedrigen T&M [Dienstvertrags]-Stundensatz, der garantiert ist und nicht zurückgefordert werden kann
- Zusätzlich gibt es bei Erreichen von definierten Erfolgskriterien eine Prämie

Der Dienstvertragsanteil

Die erste Hälfte dieser Variante ist einfach - da das BGB und das HGB die meisten Aspekte der Vertragsgestaltung für Dienstverträge weitaus besser geklärt haben als der durchschnittliche Individualvertrag lässt sich ein einfacher Dienstvertrag meistens in weniger als einer Seite abhandeln - schließlich geht es nur darum, den Stunden- oder Tagessatz festzulegen und die Form des Zeitnachweises abzustimmen. Selbst Verschwiegenheitserklärungen und Wettbewerbsregelung lassen sich auf dieser einen Seite unterbringen, wenn man sich an die herrschende Rechtslage hält und einfach auf die entsprechenden Paragraphen verweist.

Der Prämienanteil

Der Prämienanteil ist um einiges schwieriger zu gestalten, denn letztendlich handelt es sich hierbei um einen Werksvertrag – oder sogar um eine ganze Reihe davon. Und dies ist die Stelle, an der sich die Geister scheiden - soll die Prämie beispielsweise für das Erreichen bestimmter Meilensteine gezahlt werden?

• 50% der Funktionen am 31.12.?
• Wenn <Liste der features> erfüllt ist?
• Bei Produktionsstart in vollem Umfang am <Datum>?

Meine Meinung ist hier ein ganz klares Nein – zumindest bei dieser Form der Meilensteine.
Diese Art der Meilensteine bezieht sich ja wieder auf die funktionalen Beschreibungen. Die nur mit sehr hohem Aufwand formal vollständig erstellbar sind. Und genau hier sollen ja eigentlich agile Methoden weiterhelfen, indem die Anforderungen durch kurze Rückkopplungsschleifen und direkte Zusammenarbeit zwischen Kunde und Auftragnehmer innerhalb der Projektlaufzeit im Detail erarbeitet werden können. Für die Inhalte der Prämienverträge brauchen wir also andere "Meilensteine" - und eine andere Möglichkeit sie zu bewerten.

Bewertung nicht-zeitlicher Meilensteine

Wichtig für die Bewertung der Meilensteine ist natürlich vor allem, wie sie gestaltet sind – sie müssen sich auf das Ergebnis und nicht auf die Form der Umsetzung beziehen, wenn sie im Kontext agiler Softwareentwicklung sinnvoll sein sollen. Also

"Wir sind in der Lage, Änderungen innerhalb von X Minuten – komplett getestet – ohne manuelle Eingriffe für Endanwender Verfügbar zu machen"

statt

"Wir haben einen Continuous Integration Server aufgesetzt".

Nicht nur, dass die technische Aussage mit dem Continuous Intergration (CI) Server für die Kunden nur schwer nachvollziehbar ist, auch ist die technische Umsetzung noch lange kein Garant dafür, dass die erste Formulierung erfüllbar ist, wie die vielen CI-Server beweisen, die ich in den letzten Jahren gesehen habe, bei denen eine Erfolgsrate von weniger als 25% der Veröffentlichungen vorlag.

Natürlich ist die Zeit bis zur Auslieferung nur ein Aspekt - die Liste der mögliches Aspekte ist lang und sicherlich von Unternehmen zu Unternehmen und da noch mal von Projekt zu Projekt unterschiedlich.

Um aber zur Bewertung dieses Aspekts zu kommen wird der Kontext sogar noch wichtiger - den die finanziellen Auswirkungen sind natürlich von Fall zu Fall sehr unterschiedlich. Ist nur ein einziges Release pro Jahr geplant, weil es sich um embedded Software handelt und das Produkt in dem sie sich befindet nur einmal pro Jahr verschickt wird, dann ist ein hoher manueller Aufwand möglicherweise kein Problem und die (hypothetisch) notwendigen Wochen des Aufsetzens und Konfigurierens des Servers wären viel teurer als 2 Personen, die ein mal im Jahr das Zusammenstellen der Auslieferungspakete 2 Tage lang betreuen. (Die anderen Probleme fehlender kontinuierlicher Integration betrachte ich hier vorsätzlich nicht - sie sind nicht in dem genannten Ziel enthalten und sollten m.E. als separate Ziele beschrieben und bewertet werden)

Um jetzt zu einer Zahl für den Vertrag zu kommen sind allerdings tatsächlich andere Disziplinen notwendig als die Informatik – hier sind wir eher im Bereich der Betriebswirtschaft und Finanzmathematik.
Das konkrete Beispiel – automatisierte Auslieferung – würde ich noch mal unterscheiden, und zwar nach einem komplett neuen Projekt mit eigener Infrastruktur und einem Projekt, das bereits läuft bzw. sich in eine existierende Projekt-Infrastruktur eingliedern soll.

Einfache Zielbewertung bei bestehenden Vergleichsdaten

Wenn wir über die Fähigkeit des Projektes reden Änderungen ohne manuelle Eingriffe verfügbar zu machen, dann fällt die Bewertung bei einem bestehenden Projekt sehr leicht, obwohl sie durchaus aufwändig sein kann. Hier mit hypothetischen Zahlen:

Releases pro Jahr	5 mal
Bugfix-Releases pro Release bei manuellem Verfahren	2
Tage manueller Arbeit pro Release	2 tg
Personen beteiligt am Release	3 ppl

Ergibt einen minimales Kostenpotential von (5*1 + 5*2)*2*3 = 90 Tagessätzen. Bei einer angenommenen projektierten Projektlaufzeit von 5 Jahren sind das 450 Tagessätze. Ohne Betrachtung des Zinsverlaufes (Barwertbetrachtung der Zahlungsreihe), der bei fünf Jahren auch schon interessant sein kann. Hier wäre eine Prämie für die Zielerreichung von 45 Tagessätzen sicherlich angemessen.

Wohlgemerkt: die eigentliche Arbeit wird nach Aufwand im Rahmen des Dienstleistungsvertrages abgerechnet - die Prämie wird für den Mehrwert der Fähigkeit fällig. Dadurch sind beide Seiten gefordert sich sehr ernsthaft mit der Frage auseinander zu setzten, welche Fähigkeiten wie wichtig sind.

Interessant werden diese Berechnungen, wenn man sie mit dem Businessplan des Projektes vermengt - nehmen wir an, dass wir ein Unternehmen (oder eine Abteilung) mit 40 Mitarbeitern haben, das sich nach 3 Jahren aus den Erträgen der Softwarenutzung selbst finanzieren soll. Nehmen wir das Bundesweite Durchschnittsgehalt im Sektor Information und Kommunikation von 2011 laut Allensbach von 4430 € kommen wir auf einen monatlichen Bedarf von (4430 € * 40) = 177.200 € oder, geteilt durch 30, 5906 € am Tag.
Nehmen wir des weiteren an, das die beiden Bugfix-Releases deshalb nötig waren, weil das System nur eingeschränkt zur Verfügung stand und in den insgesamt 20 Tagen der Bugfix Releases noch mal 50% Umsatzeinbußen zu verzeichnen sind haben wir auf einmal weitere 59.060 €, die der Auftraggeber an Mehrwert hat, wenn der Auftragnehmer einen Teil seiner Arbeitszeit dafür einsetzt diese Fähigkeit zu erreichen.

Ähnlich lassen sich auch andere Fähigkeiten wie z.B. die Fähigkeit Regressionsfehler zu erkennen, die Vorlaufzeit für neue Anforderungen zu kennen oder zu reduzieren etc. tatsächlich finanziell bewerten - je nach Kontext und Situation.
Diese Bewertung ist aber qualitativ anders als eine klassische Meilensteinbewertung nach umgesetzten Funktionen, da wir hier tatsächlich erreichten Fähigkeiten des Prozesses, des Projektes und letztendlich des gesamten Software entwickelnden Systems - Auftraggeber und Auftragnehmer - bewerten.

Planung und Absichtserklärung für neue Situationen

Anders als bei der "einfachen" Betrachtung im Falle der bestehenden Rahmenbedingungen wird die Betrachtung bei komplett neuen Projekten um einiges komplizierter - dafür hat man hier aber auch mehr Spielraum für die Betrachtung nicht-finanzieller Werte.

Diese Aspekte des Vertragswerkes abzuklären ist nicht mit einer einfachen Checkliste wie bei der Auswahl des Sonderzubehörs für ein neues Sportcoupé zu vergleichen, sondern erfordert tatsächlich eine eingehende Beschäftigung mit den Werten von Auftraggeber und Auftragnehmer – sowohl im Sinne von moralisch-ethischen Werten (Mitarbeiterzufriedenheit ist uns wichtig) als auch im Sinne von finanziellen Werten (Neue Mitarbeiter einzuarbeiten kostet uns im Schnitt 150 Tagessätze im Jahr).

Und im Gegensatz zu den ohnehin nur schwer vorab abstimmbaren Details der Funktionen können Vertragsverhandlungen, durch die jene Werte die beide Vertragspartner in der Zusammenarbeit sehen deutlich machen und abstimmen nicht nur schlecht sein.

Hier liegt auch mein (Teil-) Wiederspruch zum agilen Manifest: Obwohl das agile Manifest sagt "Wir schätzen Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung" können Vertragsverhandlungen sehr hilfreich sein, wenn es darum geht, sich über Werte zu einigen. Sofern man sich in der Lage fühlt, Verträge über Werte statt über Tätigkeiten abzuschließen.

mögliche qualitative Meilensteine

• Lead Time (Zeit von der Idee bis zur Nutzbarkeit)
  • ist bekannt
  • ist bei N Tagen
• Anzahl wieder auftretender Fehler (Regressionsfehler)
  • ist bekannt
  • liegt bei (oder unter) N pro Release
• Kundenzufriedenheit
  • ist messbar
  • liegt bei (messbarer Größe)
• Dauer des Realease-prozesses
• Nachvollziehbarkeit der Reviews
• Testabdeckung
• Rollbackfähigkeit (nicht nur für Fehlersituationen)
• Velocity ist bekannt
• ... to be continued - by you! ...

Diese Liste ist in keiner Weise vollständig sondern nur ein Startpunkt für eigene Diskussionen - oder für die Ergänzung hier auf der Website in den Kommentaren

Weitere Aspekte

Was ist mit der Variante: Der Kunde bezahlt einfach nur die Zeit und in echter agiler Manier werden gemeinsam die aktuellen Inhalte erarbeitet?
Bei einem perfekten, vertrauensvollen Verhältnis der Parteien funktioniert dies sicher, aber – wie immer bei zeitbasierter Abrechnung – ist der größte Ökonomische Wert für den Auftragnehmer in diesem Modell zu erreichen, wenn er möglichst langsam arbeitet. Und auch wenn dies überhaupt nicht der Fall ist besteht ein gewisses Risiko, dass dem Auftraggeber in Zeiten, in denen das Projektfahrwasser rauer wird, genau diese Idee überwältigend einleuchtend erscheint und sich darüber die schöne Idee der kooperativen Zusammenarbeit ins negative wandelt.

Persönliche Fußnote:

Um Missverständnissen vorzubeugen: Ich selber ziehe für Beratung und Coaching mittlerweile Abrechnungsmodelle vor, die komplett auf dem für den Kunden erwirtschafteten Wert basieren - ähnlich den Modellen die im Abschnitt "Prämie" genannt wurden. Aber meiner Ansicht nach ist dieses Modell für komplette Projekte nur bedingt geeignet, so dass ich meine Ansichten hier im Modell "Proviant und Prämie" am ehesten wiederfinde.

Links:

[1] 10 Contracts for your next Agile Software Project | Agile Software Development

[2] Primer-Website: Agile Contracts

[3] Agile Contracts Primer

[4] Vortrag über Agile Verträge bei Agileworld

[5] Contracting for Agile Software Projects, Part 1 | Agile Software Development

[6] Verträge für agile Softwareentwicklung

Die Pyramide der Agilität

"Wir haben Scrum durch Kanban abgelöst"

"Seit wir eXtreme Programming durch Scrum abgelöst haben […]"
"Wir arbeiten nicht mit agilen Methoden sondern nach CMMI"

Sätze, die mich immer wieder verblüffen - zutiefst.

Die "Pyramide der Agilität" oder das "Agile Dreieck" sind Begriffe, die sich bei einigen Kollegen und mir über die letzten Jahre etabliert haben um das miteinander der Methoden zu beschreiben - nicht umsonst schreibt beispielsweise David J. Anderson - einer der wichtigsten Protagonisten von Software-Kanban "Kanban is not a Process"!

Aus meiner Sicht sind die agilen Methoden im Idealfall Bausteine, die zusammen eine Pyramide bilden können, in der die unteren Ebenen die oberen Ebenen stützen und die oberen Ebenen Erkenntnisgewinne für die unteren Ebenen generieren.

Um diese Sichtweise ein wenig zu illustrieren, hier meine grafische Einordnung der wichtigsten agilen (und eines nicht agilen) Schlagworte innerhalb dieser Pyramide.

Dilettierender Amateur - erstrebenswert, aber selten

Aus der Reihe: Ich glaube nicht, dass dieses Wort bedeutet, was Du glaubst, das es bedeutet...

Wir brauchen Profis und keine Amateure und Dilettanten!

Ach ja?

Wenn wir z.B. die Feinstarbeit betrachten, mit der ein Amateur-Modell-Flugzeugbauer (also jemand, der aus Liebe zur Sache Modell-Flugzeuge baut) sein Modell lackiert und z.B. dagegen stellen wie die meisten professionellen Anstreicher mit den Stellen einer Wand umgehen die "sowieso niemand sieht" (also Leute, die ihre Arbeit rein professionell, ohne Liebe an der Sache machen) stellen wir wahrscheinlich einen deutlichen Unterschied fest.

Hatte ich den Freund erwähnt, der zum fünften Mal in drei Jahren die Handwerker wegen des Schimmels an der Decke im Haus hat?

Die Worte Amateur und Dilettant stammen beide von Bezeichnungen für Leute, die Dinge tun, an denen sie sich Erfreuen. Der Profi kennzeichnet sich vom Wortstamm her vor allem dadurch, dass er (oder sie...) die jeweilige Tätigkeit "nur für das Geld" durchführt und auch die klangliche Nähe von Profi und Profit ist keineswegs ein Zufall.

Sind Sie sicher, dass Sie mehr Profis in ihrem Team brauchen?

Mehr zum Thema "Wer seine Arbeit gerne macht, macht sie auch besser" ist auch in dem spannenden (englischen) Beitrag von Daniel Pink zu finden der sich vor allem um intrinsische Motivation dreht.

Dilettant - Herkunft:
Im 18. Jahrhundert aus italienisch dilettante → it = „Kunstliebhaber“ entlehnt, das das Substantiv zu dilettare → it „erfreuen“ ist; dieses geht auf gleichbedeutend lateinisch delectare → la zurück. Strukturell ist es eine Ableitung zum Stamm des Verbs dilettieren mit dem Derivatem (Ableitungsmorphem) -ant.

Quelle: Wiktionary, Dilettant

Amateur - Herkunft:
Lehnwort des 17. Jahrhunderts aus dem französischen amateur → fr mit der Bedeutung „Kunstliebhaber“, [...]; seit dem 19. Jahrhundert in der heutigen Bedeutung, dass jemand etwas nicht berufsmäßig tut. Das französische „amateur“ wiederum geht auf das lateinische Substantiv amator (dt.: der Liebhaber, der Verehrer) zurück. Dieses Wort leitet sich von dem lateinischen Verb amare (dt.: lieben) her.[1]

Quelle: Wiktionary, Amateur

Professionell - Herkunft:
beruflich ♦ aus frz. professionnel „berufs-, gewerbsmäßig“, zu frz. profession „Bekenntnis, Erklärung; Beruf, Stand“, aus lat. professio, Gen. -onis, „öffentliche Erklärung, Bekenntnis; das (offiziell angegebene) Gewerbe, Geschäft“, zu lat. profiteri „sich öffentlich zu einem Fach, Beruf bekennen“,

Quelle: Wissen.de

Vielen Dank an einen sehr geschätzten Amateur in vielem der mich auf diese Betrachtung der Worte aufmerksam machte.

Cross functional Team - Bereichsübergreifend?

Eines der Konzepte, die aus dem TPS (Toyota Production System) ganz deutlich in die agile Welt transportiert wurden, ist das Konzept des "cross functional teams".

Aber was bedeutet "cross functional" hier eigentlich?

Ich glaube nicht, dass das Wort bedeutet, was viele denken

Die gute Praxis des "cross functional teams" wird von den meisten der agilen Prozesse in der einen oder anderen Form empfohlen oder gefordert, aber sind diese Teams wirklich im Sinne des TPS "cross functional"? Laut dict.cc wird "cross functional" mit funktionsübergreifend übersetzt, en.bab.la hingegen schlägt auch noch bereichsübergreifend vor. Das sind andere Konzepte als sie in vielen IT-Teams genannt werden. Alleine die Unterscheidungsseiten der deutschen und englischen Wikipedia bieten 13 bzw. 11 unterschiedliche Interpretationen zum Begriff "Funktion" - welche sind bei den agilen Entwicklungsteams verbreitet?

(Zu) schmales "cross functional"?

Datenbankentwickler, Spezialisten für serverseitige Programmierung und ein paar Profis im Bereich Benutzer-Interaktion. Vielleicht noch ein bisschen Webservice, REST und BPEL Know-how. Und spätestens wenn noch ein paar Betriebsleute eingebunden sind, scheinen alle Funktionen im Team verfügbar zu sein.
Fertig ist das "cross functional" Team?
Sicherlich sind Teams, die in diesem Sinne Funktionsübergreifend sind eine Form von "cross functional", die weitaus besser zu den aktuellen Herausforderungen in der Software passen als die teilweise immer noch vorhandenen separaten Client- und Server-Teams.

Aber reicht das aus?

Ein breiterer Denkansatz zu "cross functional"

Ganz anders das bereichs- und disziplinübergreifende Team, das die Aufgabe bekam das Auto zu entwerfen, das heute der Toyota Prius ist. Hier kamen nicht nur Motor-Spezialisten, Getriebe- und Beleuchtungssspezialisten mit Innenraum-Designern und Spenglern zusammen, hier war das – grade mal 10 Personen umfassende – Team ebenso mit Marketingleuten, Buchhaltern und Einkäufern besetzt, wie mit Technikern.

Quelle: leider fragwürdige, persönlich Unterhaltung, ungefähr 2003

Unabhängig davon, ob es nur eine schöne Geschichte ist, oder eine leider viel zu schlecht für Suchmaschinen optimierte reale Fallstudie - für mich ist der Gedanke absolut schlüssig:

Wir ziehen heutzutage die Grenzen des Teams oft an ungünstigen Stellen - "cross functional" sollte nicht heissen "IT-ler aller Art" sondern "Ein Team mit dem Know-how aus allen beteiligten Bereichen - auch mit IT-lern und Informatikern"

XP mit seinem Kunden im Team (On-Site Customer) geht da schon einen guten Teil des Weges, aber wirklich funktionsübergreifende und bereichsübergreifende Teams können nicht aus einer Funktion - oder einem Bereich alleine aufgebaut werden - sie müssen tatsächlich auch Bereichsübergreifend aufgebaut werden.

Das technisch "cross functional" aufgestellte Team ist meiner Ansicht nach mal wieder Notwendig, aber nicht hinreichend.

Cheers
   Michael

Vom Beamen und von Meetings - Science Fiction "im Enterprise"

Manchmal scheint in Unternehmen der Größenklasse "Enterprise" vergessen werden, dass die Beamer, die man zu den Besprechungsräumen buchen kann, nichts mit dem – ebenfalls "beamen" genannten – Ort-zu-Ort-Versetzen aus dem Raumschiff "Enterprise" in "Star Trek" zu tun haben.

Wie ich zu dieser Einschätzung komme?

Natürlich aus den Kalendern und Termineinladungen.

10:00 - 11:00 Vertriebsmeeting in Haus 1
11:00 - 12:00 Design-Sitzung in Haus III
12:00 - 13:00 Besprechung kanonisches Datenmodell Haus IIV
13:00 - 13:30 Strategie-Abstimmung beim Lunch im Freigelände
13:30 - 14:00 Präsentation beim Vorstand (42. Etage Hochhaus)

Da nach meiner Erinnerung selbst das Beamen bei Star-Trek ein paar Sekunden in Anspruch nahm, ist mir völlig unklar, wie irgendjemand die Phantasie entwickeln kann, das ein solcher Terminplan funktionieren kann.

Strategie für Meeting-Einladungen

"Krumme" Zeiten für die Einladungen - z.B. 11:05 bis 11:40 - und ein konsequentes Einhalten beider Endpunkte als Einladender.

Warum solch exakte Angaben?

Einerseits ist es leichter von Meeting zu Meeting zu kommen, andererseits ist es unwahrscheinlicher, dass noch jemand ein Meeting direkt auf Stoß davor plant. Und schließlich werden bei solch exakten Uhrzeiten von den meisten Lesern geringere Toleranzen angenommen.

Scrum Master? Coach? Selbstorganisation?

Heute im Chat - Nur leicht anonymisiert und mit Freigabe des Chatpartners:

• "Ein Freund": Ich finde, die Rolle des Scrummasters wird oft unterschätzt.
• ich: ?
• "Ein Freund": So nach dem Motto, den brauche man ja nicht weil selbstorganisiert.
• ich: Jo - beliebte Fehlinterpretation
  Allerdings geht es ja nicht um den Scrum-Master in der Defintion des Scrum-Guide Meiner Ansicht nach gibt es die entsprechende Rolle in jedem methodischen Ansatz zur Softwareentwicklung - mal ist es der XP-Coach, mal der Scrum Master und mal einfach der Coach
• "Ein Freund": Und wenn die Rolle nicht besetzt ist, kommt sowas bei raus wie bei uns.
• ich: Yep - leider ist das so. Und das ist eines der größten Probleme von Scrum
  Vor allem, wenn die Unternehmen ihre Probleme mit "Scrum" lösen wollen
  Deshalb ist XP m.E. auch nicht so erfolgreich - da wird von vornherein zu deutlich gesagt, dass man viel Disziplin braucht und das es wirklich schwer ist etc.

Passt gut zu meiner aktuellen Kritik an Scrum:
Wenn man Scrum auf die so plakativ z.B. in Scrum in one Minute beschriebenen 3 x 3 Elemente reduziert fehlt auf einmal sehr viel.
Scrum kann aus meiner Erfahrung sehr gut ein Element auf dem Weg zu funktionierenden Projekten sein, aber in dieser über-minimalistischen Form, ohne Praktiken und ohne Details, meiner Ansicht nach keinesfalls das einzige Element.

Meine 2 cent:

Auch wenn ich sehr wenig von "der Deutschen liebstem Sport *" verstehe, so bin ich mir doch sehr sicher, dass es nicht reicht, das veraltete WM-System durch die Viererkette zu ersetzen - die Spieler brauchen sicherlich auch noch andere Fähigkeiten und Fertigkeiten um siegreich zu sein und viele davon dürften direkt mit dem Medium mit dem sie umgehen – dem Ball – und dessen Nutzung innerhalb des neuen Konzeptes zu tun haben.
Und vor allem sind mehr als die elf Personen auf dem Platz beteiligt - sonst müsste ja nicht immer der Trainer gehen, wenn die Mannschaft verliert.

Ähnliches bei der Softwareentwicklung im Hinterkopf zu haben ist sicherlich keine schlechte Idee.

[Gleiches gilt natürlich für Software-Kanban, obwohl es sich dabei ja ohnehin nicht um einen Prozess handelt, sondern um eine Methode zur Prozessverbesserung... wie auch schon David Anderson sehr deutlich machte auch wenn man diesen Beitrag heute nur noch in den Yahoo!-Groups archiven und nicht mehr auf Davids eigener Website findet.]

---

*(gemeint ist hier übrigens Fußball. Wenngleich der vor allem angeguckt wird, während der tatsächlich aktiv ausgeübte Sport Nummer Eins laut der Augsburger Allgemeinen das Radfahren ist.)

Technische Unfähigkeit bei Konzernen, Folge n+1 (Flinkster und Deutsch Bahn)

Disclaimer: Ich weiss, dass es kindisch ist, diesen Eintrag zu schreiben, aber da ich schon gerade dabei war, mich aufzuregen...

Schon mal versucht einen Flinkster Vertrag online abzuschließen?
Wenn ja, dann hoffentlich mit einem Windows-Rechner mit der richtigen Version von Microsoft™ Word.

Hier die Mail, die ich (ohne viel Hoffnung auf sinnvolle Reaktionen) gerade an Flinkster geschickt habe:

====8<----- snip ----

Sehr geehrter Damen und Herren,

der zur Vervollständigung des Anmeldeprozesses auszudruckende
Vertrag liegt leider in einem Format vor, welches von meinen
Systemen nicht verarbeitet werden kann.
(Es scheint sich hier um ein Mircrosoft-Word Derivat des
Formates RTF zu handeln)

Bitte lassen sie mir den Vertrag in einer nicht
herstellerspezifischen Form zukommen.

Beispiele für solche übergreifend nutzbaren Formate sind:
* Rich Text Format (rtf) [Standardkonform]
* Portable Document Format (pdf)
* Postscript (ps)
* Hypertext Markup Language (html)
* Tagged Image File Format (TIFF)
* Portable Network Grafics (png)

In der Anlage erhalten sie in Form einer png Datei ein
Beispiel dafür, wie der Vertrag aussieht, der durch das
für die Flinkster Website derzeit eingesetzte System
erstellt wird, wenn er /ohne/ Microsoft Word
ausgedruckt wird.

Mit freundlichen Grüßen
Michael Mahlberg
--
TCG The Consulting Guild AG * Friesenwall 126 * 50672 Köln
Mobil: +49 160 97856224 * Büro: +49 221 677742111 * Fax: +49 221 677742119
HRB (Köln): 63476, Vorstand: Michael Mahlberg (V)
Vorsitzender des Aufsichtsrates: Daniel Speicher


(Nein, die schwärzungen stammen nicht von mir, sondern sind das ergebnis des heruntergeladenen Vertrags)
====8<----- snip ----

Mittlerweile habe ich mich auf ein paar anderen Rechnern ausgetobt: Mit Microsoft Word auf dem Mac sieht es halbwegs vernünftig aus - Zeichensatzprobleme nicht mitgerechnet.

Scrum? Das ist doch das mit den Kreisen!

Na Super!
Vielen Dank auch an die Marketing-Spezialisten...

(Die Titelzeile "Scrum? Das ist doch das mit den Kreisen!" ist ein reales Zitat von einem Networking-Treffen im Herbst 2010...)

Das einfache Bild (dass ja bekanntlich sogar auf einen Bierdeckel passt ist) hat sicherlich viel dazu beigetragen, Scrum und auch dem Gedanken agiler Prozesse ganz allgemein zu der heutigen Akzeptanz zu verhelfen.

Als "hilfreiche Vereinfachung um die Grundgedanken von Scrum zu transportieren" kann ich mit diesem Bild leben. Zur Einführung eines Scrum-basierten agilen Prozesses werden aber meiner Erfahrung nach doch einige Aspekte mehr benötigt.


("Standard"-Bild zu Scrum)

Die andere Seite - das Produkt ist nicht das einzige, was durch einen Scrum-basierten Prozess verbessert wird - wird zunehmend auch wahrgenommen, wie David Harvey in seinem Beitrag deutlich macht.


(David Harveys Bild zu Scrum )

Was David Harvey hier herausstellt ist die Tatsache, dass neben dem eigentlichen Produkt durch den Prozess selber auch noch ein Team und ein im Team gelebter, konkreter Prozess erzeugt werden, die sich auch mit jedem Inkrement verbessern.

Was man darüber hinaus aber nicht vergessen darf ist, ...

[Vorsicht, Analogie für Softwareentwickler, die Objektorientierung kennen]

dass Scrum so etwas ist wie eine abstrakte Klasse - man kann es nicht instantiieren ohne die spezifizierten Methoden zu implementieren - und wenn man die Implementierung nur in Form von leeren Stubs durchführt kann man auch kaum erwarten, dass die Instanz sinnvolle Arbeit leistet.

[Nach einer guten Analogie für BWL oder PMI Spezialisten suche ich noch, hier die schlechte]

dass Scrum nur den groben Bauplan vorgibt - wie bei einem "Standardhaus", welches man so auch nicht bauen kann ohne sich nicht zu entscheiden, wie man bei diesem konkreten Exemplar die Wände zieht, was für Treppen man einsetzt und wo welche Anschlüsse nun wirklich liegen sollen.

Das reale Bild - und auch hier sind noch nicht alle relevanten Details aufgeführt - sieht dann eher so aus wie diese konkrete Instanz eines Scrum-basierten Entwicklungsprozesses:

(um Missverständnisse zu vermeiden: Dies war eine konkrete Ausgestaltung für ein konkretes Team - bitte nicht verallgemeinern!

Was ich damit deutlich machen will ist folgendes:
Ja, auf einer abstrakten Ebene ist Scrum ganz einfach - genau so, wie beispielsweise ein Auto auf einer abstrakten Ebene ganz einfach ist: drei bis vier Räder, Motor, Getriebe, Bremsanlage, ein paar Schaltelemente und eine selbsttragende Karosserie, fertig ist das Auto. Aber der Unterschied zwischen einem Benz Patent-Motorwagen Nummer 1 und einem Tesla Model S (oder irgend einem anderen aktuellen Fahrzeug) liegt sicher nicht nur im unterschiedlichen Zeitgeschmack, was die Gestaltung der Speichen anbelangt.
Nein, es reicht nicht, wenn man sich den Bierdeckel nur lange genug anguckt. Wenn man eine auch nur halbwegs konkurrenzfähige Umsetzung des einfachen Konzeptes haben will, dann muss sich sich intensiv mit den Details auseinander setzen und auch bereit sein, diese von Generation zu Generation (oder in unserem Fall von Iteration zu Iteration) zu überdenken.

Kreation statt Konsum! (diesmal per Mail)

Die allgemeine Meinung zum iPad scheint zu sein, dass es vor allem ein Werkzeug zum mobilen konsumieren digitaler Informationen sei. Ich selber kann mich dieser Sicht kaum anschließen und nutze es vor allem zum kreieren von Sachen (vor allem von Texten, die ich unterwegs schreibe).

Um nun auch meinen Blogs mal wieder ein wenig mehr Leben einzuhauchen Teste ich gerade verschiedene Möglichkeiten, Blogposts vom iPad aus zu erzeugen und zu verschicken.

Mail scheint schon eine erheblich bessere Variante zu sein um die Posts zu erzeugen, aber leider fehlt auch hier die Möglichkeit, eine vernünftige semantische Formatierung vorzunehmen.

- Listen
- Überschriften
- Hervorhebungen
- Zitate

Formatierungen wie fett, kursiv und Unterstrichen funktionieren nicht mal, wenn man die Inhalte aus einem Programm kopiert, dass diese Formatierung kann. (Wie dieser Absatz beweist)