storz.net

"On Hold" im Kanban Prozess

Sun, 06 May 2012 08:52:00 -0600

Unser Team hat mit einem On-Hold-Feld im Kanban experimentiert. Wenn ein Task in Ongoing auf eine Kundenrückmeldung warten muss, ging die Karte in diese On-Hold-Feld, das sich in der entsprechenden Ongoing-Spalte befindet. Die WIP-Limits galten nicht (!) für On-Hold, weil ja niemand daran arbeitet. Unter dem Strich hat sich herausgestellt, dass das keine gute Idee war, und zwar, wie ich glaube, aus mehreren Gründen.

Das On-Hold-Feld wurde relativ schnell zum unbeobachteten Parkplatz, weil es keine Policy gab, wie lange man warten muss/darf. Kunden melden sich zum Teil Wochen nicht, und es besteht kein Zwang, sich die Tasks im On-Hold-Feld anzuschauen, weil ja der Kunde am Zug ist.
Das WIP Limit wurde dabei umgangen und gebrochen. In einer Ongoing-Spalte mit einem Limit von 7 waren zusätzlich 12 Karten in On-Hold. Das Problem: Wenn der Kunde sich dann meldet, muss man entscheiden, ob man an der On-Hold-Karte weiterarbeitet -- und sie damit nach Ongoing zurück schieben. Damit wird klar: On-Hold in dieser Form ist letztlich auch Ongoing. Die Folge war Punkt 3:
Probleme wurden zu spät sichtbar. Weil das On-Hold ein Bermuda-Dreick war, in das man einen Task parken kann, ohne dass er weiter im Flow auftaucht, wurde erst mit der Zeit sichtbar, dass Ongoing überlastet ist. Der Sinn von Kanban, Engpässe so früh wie möglich sichtbar zu machen, ging verloren, und der Flow wurde schlechter.

Lesson learned: Kanban On-Hold? Use with caution!

Letztlich widersprach das Experiment in dieser Form m.E. drei Kanban-Core-Praktiken: "Limit WIP", "Manage Flow" und "Make policies explicit".

Der Flow wurde durch das On-Hold-Feld verschlechtert und zum Teil wurde implizit von Pull auf Push umgestellt -- der Kunde pusht, indem er sich rückmeldet, und wir wissen nicht, woran wir weiter arbeiten sollen.
Die WIP-Limits wurden (unbewusst) gebrochen.
Es gab keine explizite Policy, was zu tun ist mit Karten, die aus dem Wartezustand zurückkommen.

Der Grund für On-Hold ist letztlich, dass man auf den Kunden reagieren will, wenn er sich zurückmeldet. Man müsste Kunden dabei aber vielleicht informieren, dass sie sich in einer festgelegten Zeit melden müssen, sonst kann man die reibungslose Abarbeitung nicht garantieren. Das ist trivial, aber manchen Kunden irgendwie nicht klar. ;) Wenn die Rückmeldung nicht innerhalb dieser Zeit kommt, geht der Task zurück ins Backlog. Man kann ihn dann hochpriorisieren, wenn das Kundenfeedback kommt, evtl. in die Fast Lane oder eine höhere Service-Klasse, wie David Anderson vorschlägt.

Vorschläge von David J. Anderson

David J. Anderson macht auf meine diesbezügliche Frage auf der Kanbandev-Liste hin noch einige Vorschläge. Sein Feedback sagt: Die Frage käme oft und es gebe hier keine richtige vs. falsche Antwort, unser ursprünglicher Ansatz sei jedoch "lower maturity behavior". Mein Vorschlag sei ok, aber je nach Kunden evtl. nicht gut vermittelbar und auch nicht sehr agile, weil ich darauf warten möchte, dass alle notwendige Informationen zur Verfügung stehen. Eher müsste man die Policies bewusst und explizit beschließen, je nach Ziel, das man verfolgen will, also zum Beispiel klären, welchen Stellenwert eine Karte hat, die aus dem Wartezustand zurückkommt. Sein wichtigster Tipp war ein allgemeiner: The important thing is to ask yourself "what behavior do I want to see as an outcome?" then design the kanban system to provoke (or catalyze) this behavioral change. Heißt für uns, denke ich: Wir müssen überlegen, wie wir Kunden belohnen, die adäquat antworten, wie wir mit Kunden umgehen, die zögerlich antworten, wir müssen überlegen, ob ein Task mit viel Kundeninteraktion generell eine andere Klasse bekommt, oder dann, wenn er aus der Warteposition kommt (z.B. Fast Lane) usw.usf.

Nachlese zur FLOW3 Experience F3X12

Wed, 11 Apr 2012 00:00:00 -0600

Die FLOW3 Experience 2012 war die erste Konferenz zu FLOW3, dem PHP Framework aus dem TYPO3-Ökosystem. Im Oktober 2011 schlug ich Josef und Stefan Willkommer (den Inhabern von TechDivision) vor, eine Konferenz zu FLOW3 zu machen. Mit dem Thema hatten wir – halb erhofft, halb mit Glück – genau das Richtige zum richtigen Zeitpunkt gewählt. Nachdem FLOW3 im Oktober in 1.0 released wurde, war klar, dass es v.a. in der TYPO3-Community an Fahrt aufnehmen würde. Wie stark und wie schnell, wusste man natürlich nicht. Mit circa 170 Besuchern ist das Event, das gebe ich zu ;), viel besser aufgenommen worden, als erhofft.

Was braucht man für eine Konferenz? Sponsoren, Speaker, Location...

Man hat es auch an den Sponsoren gemerkt, es war extrem einfach und ging extrem schnell, Sponsoren zu finden. Natürlich sind das größtenteils die "üblichen Verdächtigen", die man immer auf TYPO3-Events findet, jedoch gibt es inzwischen so viele Veranstaltungen, dass jeder Sponsor bewusst auswählen muss, was er mitmacht. Neben fünf offiziellen Events und den vielen Camps, der T3AK, T3Uni (Fr) usw. eine weitere Sache im TYPO3-Universum zu etablieren, schien riskant. Die Sponsoren sind aber schnell und zahlreich an Bord gekommen, das hat Mut gemacht. Und ohne Sponsoren geht es nicht. Die F3X12 hat über 20.000 Euro gekostet, und wir haben die Ticketpreise bewusst sehr niedrig gehalten. Ohne Sponsoring und die Finanzierung von TechDivision (meinem Arbeitgeber, dem Veranstalter:) wäre die Sache unmöglich gewesen. Als dann Mitglieder des FLOW3 Core Team, allen voran Robert Lemke und Karsten Dambekalns, zusagten, wusste ich, das könnte was werden. Zugeben, die Location in Kolbermoor – das Kesselhaus – ist toll, aber das weiß niemand außerhalb von Rosenheim, und ich war mir nicht sicher, ob man die Leute alle dazu bekommen würde, nach Rosenheim zu fahren. Mit dem tollen Speaker Lineup schien es mir dann aber plausibel, dass die Besucher den Weg auf sich nehmen.

Was gut lief, was nicht

Insgesamt war der Tag ein voller Erfolg, das sage ich jetzt einfach mal so. Speaker, FLOW3 Core Team, Sponsoren, Gäste, TechDivision, alle meldeten zurück, dass es eine gute Veranstaltung war. Dennoch soll und muss man in einer Restrospektive anschauen, was ist noch zu optimieren, was hat den Leuten nicht so gefallen, denn: Nach der Konf ist vor der Konf. Die zwei deutlichsten Kritikpunkte, die wir in der Feedback-Umfrage unter Teilnehmern bekommen haben, waren die technischen Schwierigkeiten und die Stühle. Ich wusste im Vorfeld nicht, welche Bestimmungsstücke einer Konferenz man nicht 3x sondern 10x testen muss, und jetzt weiß ich es. Natürlich war die Technik mit dem Kesselhaus besprochen und getestet, aber hier muss man wohl – will man 100% sichergehen – Fallbacks und Sekundärsysteme haben. Das Problem: Das geht nicht. Bzw. nur mit einem nicht bewältigbaren/bezahlbaren Aufwand. Ein bisschen Risiko bleibt immer, und da hatten wir ein wenig Pech. Die Audio-Technik kann man aber besser absichern, das werden wir auch machen. Am Ende hat das Problem mit dem Beamer nur circa 10 Minuten gekostet, dann war das defekte Kabel gefunden, aber so etwas merken sich die Leute. Auch dass das WLAN irgendwann ausfallen würde, war mir eigentlich klar, ich habe ehrlich gesagt noch nie eine Konferenz erlebt, wo das nicht der Fall war. Dass es dann gar so langfristig zusammenbrechen musste... Die Haustechnik des Kesselhauses ist nicht auf Techie-Konferenzen eingerichtet und auf ultraschnelles Debugging auch nicht, da müssen wir das nächste Mal klar eine robustere Lösung finden, was die APs betrifft, ein Ansatz, der mehr unter unserer Kontrolle steht. Und die Stühle: Das hat mich kalt erwischt. Ich selber hatte keine Probleme, weil ich auch viel auf den Beinen war und nicht den ganzen Tag auf so einem Stuhl saß. Vielleicht mieten wir 2013 dann noch 200 Kissen. ;) Auf jeden Fall werden wir nicht mehr so eng stellen. Und wir werden einen separaten Entwickler-Raum einrichten, in dem man sich unterhalten und arbeiten kann. Mir war im Prinzip klar, dass das nice2have ist, wir haben es in der Planung aber nicht berücksichtigt, weil wir längst nicht mit so vielen Besuchern gerechnet haben, dann wär das deutlich weniger problematisch gewesen. Dann war die Zeit zu kurz und zu viel anderes zu tun, um das noch zu organisieren.

Feedback Statistics

Was ich an unserer Teilnehmer-Umfrage insgesamt auch gemerkt habe (und damit muss ich halt leben): Man findet für jedes m.E. noch so gelungene Detail jemanden, der unzufrieden war. Da muss man wohl das oberste und unterste Perzentil des Feedbacks wegschneiden und resümieren, dass man es niemals allen recht machen kann. Insgesamt haben wir mit der Schulnotenmittelwert von 1.3 auf die Frage "Wie hat Dir die F3X insgesamt gefallen" und 76% Antworten "Auf jeden Fall" auf die Frage, ob man nächstes Mal wieder dabei wäre (und noch mal 7%, die deutlich zu Ja tendieren), ein echt schönes Ergebnis. Auch einige Sponsoren haben gleich signalisiert, dass sie wieder dabei sein werden im nächsten Jahr. Das hört sich doch gut an.

Warum eine Konferenz machen?

Die Gretchenfrage: Hat es sich gelohnt? Klar, spaßtechnisch war es ein Bringer! Aber irgendwer zahlt auch die Zeche, und ein solches Event, auch in dieser noch eher bescheidenen Größenordnung, macht Arbeit, wer hätts gedacht. Von TechDivision stecken um die 200 Stunden in der Konferenz, Freizeit und den Tag selbst nicht mitgerechnet. Je nach Berechnung ist das eine beachtliche bis richtig beachtliche Summe Geld. Ich persönlich hatte einfach "Bock", wie man so schön sagt, und habe auch viel gelernt und viel Spaß gehabt und viele interessante Leute näher kennengelernt. Aber ohne Firma im Rücken, die das trägt, geht so was natürlich überhaupt nicht. Für TechDivision als Firma, denke ich, hat es sich auch gelohnt. Man macht so eine Konferenz, weil man an der Community teilhaben und das Projekt FLOW3/Phoenix/TYPO3 unterstützen will (was zugleich altruistisch und egoistisch ist). Und aus Marketinggründen, ganz klar, um Sichtbarkeit zu erhöhen, Expertise und Präsenz zu zeigen, um sich zu positionieren. Man macht es, das muss man ganz klar sagen, nicht fürs Geld. Wir sind knapp im Plus rausgekommen, aber das hätte auch ganz anders laufen können. Will man Konferenzen aus ökonomischen Gründen veranstalten, muss man gänzlich anders vorgehen, das ist im TYPO3-Feld m.E. auch praktisch unmöglich, weil es so viele hochqualitative Community-Events gibt, die extrem viel bieten für extrem wenig Geld. Hier unterscheidet sich das TYPO3-Ökosystem m.E. deutlich von anderen Open-Source-Communities (ganz zu schweigen vom rein kommerziellen Sektor natürlich) – ich kenne kein anderes Projekt, in dem es so viele gute Events gibt. Es freut mich, dass wir mit der F3X eines hinzufügen konnten, das sich hoffentlich etabliert, da bin ich mir eher sicher. #toitoitoi

FLOW3 Experience 2013

Die "Learnings", wie man in Agentur-Deutsch so gerne sagt, was wir nächstes Jahr anders machen werden:

Alles auf Englisch.
Vermutlich 2 Tage, dafür mehr Pausen.
Der Workshop am Vortag wird klarer vordefiniert, evtl. gibt es zwei.
Industrial grade WiFi.
Pultposition und Bühnenbeleuchtung optimieren.
Separater Aufenthaltsraum mit Tischen, Netz und Strom.
Kissen für die Stühle?!
Noch mehr Social Media im Vorfeld und währenddessen.
Und eins noch: Beim DJ wird es keine Demokratie geben, sorry, Leute! ;))

Unterm Strich bleibt für mich ganz persönlich, ich sage das so lapidar und umgangssprachlich: Es war geil! :) Danke an alle! Links

Videos, Slides, Fotos, Berichte zur FLOW3 Experience
FLOW3 Projekt Website
Events im TYPO3 Universum

Kanban in der Wissenschaft

Mon, 09 Apr 2012 08:11:00 -0600

Kanban ist eine agile Change Management Methode, ihre zwei einfachsten und wichtigsten Ansätze sind:

> Visualisierung
> Work in progress limitieren (WIP Limits)

Darüber hinaus gibt es eine Reihe von möglichen Regeln, Methoden, Statistiken und Anpassungen, an dieser Stelle will ich nicht ins Detail gehen, nachzulesen ist das z.B. bei einschlägigen Consultants, in der Kanban-Yahoo-Group und in Informationen der Lean Kanban University. Wohlgemerkt ist Kanban gemeint, wie es v.a. von David J. Anderson in der Software-Industrie eingeführt wurde, nicht das "klassische" Kanban bei Toyota.

Value Stream Mapping

Um Kanban einführen zu können, muss man sich Gedanken machen über den Value Stream, also den Wertstrom, die verschiedenen Phasen, die ein Produkt durchläuft. In der herstellenden Industrie ist das naheliegend, weil ein Auto eben nach und nach zusammengebaut wird. Auch in der "Wissensarbeit" findet man in aller Regel aber klar abgegrenzte Phasen, die aufeinander folgen. Den Prozess, diese zu erarbeiten, nennt man Value Stream Mapping. Für die Software-Herstellung sind das zum Beispiel die Phasen Analyse, Imlementierung, Testing, Deployment. Sobald man einen Value Stream definiert hat, kann man jede Aufgabe einer dieser Phasen zuordnen, sprich: Das Kanban-Kärtchen, auf dem die Aufgabe notiert ist, in eine Spalte des Kanban-Boards hängen, etwa die Aufgabe "Feedback-Formular bauen" in die Spalte Testing. Die eigentliche fundamentale Neuerung bei Software-Kanban besteht darin, dass man die Anzahl an Kärtchen pro Spalte limitiert, weil sich zeigt, dass die Bearbeitung von zu vielen Dingen gleichzeitig den Überblick, den Durchsatz, die Planbarkeit und die Qualität verschlechtern. Schon die Visualisierung aller anstehenden Aufgaben an einem Ort, dem Kanban-Board, bringt dabei eine extreme Verbesserung, weil alle Beteiligten direktes Feedback über Prozesse, Engpässe, Probleme und die Workload haben.

Value Stream in der Wissenschaft

Im Gespräch mit meiner Frau über Kanban (das wir in der Agentur verwenden und auch ich allein mit Personal Kanban) wurde schnell klar, dass die Aufgaben, die in der Forschung bestehen, sich sehr einfach in einem Value Stream darstellen lassen, der über die meisten Vorhaben hinweg gleichbleibend ist. Wissenschaftliche Arbeit heißt (natürlich nicht ausschließlich):

Planung (was beforschen wir spezifisch innerhalb des Projekts?)
Literaturübersicht (was gibt es dazu schon?)
Entwicklung des Konzepts (welche Hypothesen haben wir?)
Datenanalyse (Statistiken, Auswertungen)
Methoden-Teil schreiben
Einleitung der Arbeit schreiben
Diskussionteil schreiben
Rest schreiben
(diese Reihenfolge wird überraschenderweise fast immer eingehalten)
Paper einreichen (Champagner!)

Dieser Value Stream wird dabei im Team abgearbeitet. Ideale Voraussetzung für Kanban. Deshalb hängen nun im Max Planck Institut neuerdings, wie ich mit Stolz sage, Post-It-Zettel an der Kanban-Wand, siehe Bild. Da die Tasks pro Spalte mehrtägig sind, verzichtet die Arbeitsgruppe auf tägliche Standups, die jedoch wöchentlich regelmäßig stattfinden. Mir persönlich hilft schon, wie erwähnt, alle anstehenden Aufgaben an einer Wand gesammelt zu sehen. David Anderson spricht hierbei, wenn man also nur Visualisierung und WIP-Limits anwendet und nicht alle 5 Kanban-Core-Praktiken, von einer "shallow implementation". Ich finde aber, dass eine Kanban-Implementierung, wenn man sie ernsthaft betreibt, von den ersten 2 automatisch zu den weiteren 3 Core-Praktiken tendiert. Die Abwertung in "shallow" finde ich persönlich deshalb eher unpraktisch.

Kanban mit operantem Konditionieren

Die Arbeitsgruppe am MPI bestünde nicht in der Mehrzahl aus Verhaltenstherapeuten, wenn sie nicht Prinzipien der skinnerschen Verstärkung beherzigen würden. Deshalb gibt es beim Einreichen einer Arbeit eine Flasche Sekt zur Belohnung. Dies ist auch auf der Definition der Kanban-Spalte (im Bild ganz rechts in Pink) festgehalten als Piktogramm. Insofern würde ich sagen, dass auch die vierte der o.g. Core Practises erfüllt ist, nämlich Make Process Policies Explicit. Deshalb bin ich guter Dinge, als frisch gebackener Agile Consultant eine Deep Implementation von Kanban auf den Weg gebracht zu haben. Und das für lau! Links:

Kanban-Yahoo-Group
Lean Kanban University
t3n-Artikel zu Kanban
Deutsche Limited-WIP-Society

Sustainable Pace und Mastery Mode

Wed, 14 Mar 2012 11:46:00 -0600

In den Prinzipien des Agile Manifesto ist die Rede vom Sustainable Pace, dem nachhaltigen Arbeitstempo. Damit ist gemeint, dass nächtelange Endspurte, Überstunden und 150% Auslastung nie eine Lösung sind, nicht nur, weil man sie nicht auf Dauer durchhält, sondern auch, weil sie zu schlechten Ergebnissen führen. Ich will behaupten, dass man unter Stress und Druck zudem zu einer kognitiven Lage tendiert, die für Knowlegde Work generell ungünstig ist.

Der Mastery Mode
Vielleicht kennt jeder dieses Phänomen, ich habe es an mir und anderen beobachtet: Wird man etwas gefragt, ist man eher in der Lage, eine sinnvolle Antwort zu produzieren, als wenn man in der Rolle des Fragenden für dieselbe Frage ist. Die Rollenzuschreibung, sozial oder selbst initiiert, bestimmt die Qualität der Performance*. Das klingt trivial, ich finde es aber immer wieder frappierend, denn es heißt: Je nachdem, in welcher Rolle man sich befindet, greift man unterschiedlich gut auf eigene Ressourcen zu. Bin ich mir unsicher und frage einen Kollegen "Wie ist das mit IPv6, gibt es da auch Masquerading?", habe ich m.E. nicht dieselbe kognitive Strategie bzgl. meines vorliegenden Wissens, wie wenn ich dasselbe gefragt werde. (Das gilt nicht für klinische Narzissten btw, aber für die meisten Menschen, denke ich.;) Die Selbstwirksamkeitserwartung bestimmt also darüber, wie erfolgreich ich mich verhalte, auch, was intrapsychische Strategien betrifft. Das ist vermutlich niemandem etwas Neues. Ich nenne des Modus, in dem ich mich als qualifiziert sehe/empfinde und in dem ich deshalb tatsächlich besser arbeite, im Folgenden den Mastery Mode. Es gibt Menschen, die eher die Souveränität besitzen, eigene Mängel, Problemsituationen oder Krisen nicht als bedrohlich zu empfinden, also wahrscheinlicher im Mastery Mode arbeiten. Dieses Mind-Set "Ich kann was, ich weiß was" könnte man mit "Selbstbewusstsein" generalisieren, ich glaube aber (und darum geht es in diesem Posting), es geht nicht nur um Selbstbewusstsein. Es geht auch um den psychischen Spielraum, den ich mir in der Folge gestatte. Und wiederum in der Folge: Dass dann meine Performance besser ist.

Stress ist nicht cool, Stress ist schlecht
Wenn ich unter Stress stehe, bin ich weniger wahrscheinlich im Mastery Mode, ich mache mehr Fehler, zweifle eher, habe einsilbigere Lösungsstrategien, aber nicht, weil ich unter Stress weniger weiß oder potentiell weniger kann oder (sic) weniger selbstbewusst bin. Sondern, weil ich unter Stress weniger "Freiheit im Kopf", weniger psychischen Spielraum, weniger spielerische, kreative Herangehensweise habe. Phylogenetisch finde ich das naheliegend, weil Säugetiere in aller Regel dann unter Stress sind, wenn es nicht um kognitive Lösungen geht, sondern ums Wegrennen oder Zubeißen. Jim Benson beschreibt das in Personal Kanban sehr schön: Wenn man an die Auslastungsgrenze kommt, sagen wir mit 5 Tasks gleichzeitig, hat man nicht nur mit den 5 Tasks zu kämpfen, sondern auch mit dem Stress, denn die Nahe-100%-Auslastung erzeugt, mit der Frage "Wie könnte ich das noch alles in den Griff kriegen", mit der Angst "Schaff ich das noch?". Das beeinträchtigt die Performance deutlich. Im Grunde weiß das jeder. Obwohl es gemeinhin klar ist, dass Stress die Leistungsfähigkeit negativ beeinflusst, wenn es sich um Knowledge Work handelt, gilt es in der Arbeitswelt immer noch als schick, im Stress zu sein. Wer im Stress ist, ist wichtig. (Wer im Stress ist, kann übrigens auch Aufgaben ablehnen, weil im Stress zu sein, eine akzeptable Ausrede ist, aber das ist eine andere Geschichte.) Dabei ist Im-Stress-Sein einfach nur effizienzmindernd und ungesund. Ich finde es eine elementare Errungenschaft der agilen Philosophie, dass sie deutlich macht: Unter Stress arbeiten, ist der falsche Ansatz. Ziel is vielmehr, aus dem Notlösungs-Modus wieder in den spielerischen Modus zu kommen. Out of the box thinking. Souveränität. Mastery Mode. Freiraum im Kopf und Selbstwirksamkeitserwartung sind es, worauf es ankommt. Wenn man nicht fragt "Wie krieg ich es gerade noch gebacken?", sondern "Was wäre denn ideal?", kommt man auf eine Lösung, die evtl. minimal mehr Arbeit macht, aber extrem viel besser ist.

Grenzen des Laid-Back... Und die Adrenalin-Falle
Es ist klar, dass das nicht immer funktioniert. Wenn die Hütte brennt, muss gelöscht werden, Mastery Mode hin oder her. Dann muss man sich fragen, was grundsätzlich zu ändern ist. Ein Verdienst von Kanban etwa ist es, schnell offensichtlich zu machen, wo Probleme und Stress entstehen. Es ist gefährlich, auf den Adrenalinrausch, den eine brennende und gerade noch gelöschte Hütte bedeutet, hereinzufallen. Alle klopfen sich auf die Schulter, Mensch, was haben wir für einen Stress gehabt und wie toll sind wir, dass wir noch leben. Die Hochstimmung, gerade noch eine Katastrophe abgewendet und alles irgendwie hinbekommen zu haben, ist sonst nur mit Drogen herzustellen. Henrik Kniberg beschreibt in Lean from the trenches als Gegenbeispiel und Vorbild, wie Releases (wenn man alles im Griff hat) irgendwann nicht mehr schrecklich aufregend und aufregend schrecklich, sondern Alltag sind. So dass gar nicht mehr auffällt: Wir haben landesweit ein Release ausgerollt. Weil alles wie selbstverständlich funktioniert. Mancher wird sich im Scherz zurücksehnen nach den nächtlichen Panik-Aktionen... Aber um es noch mal festzuhalten: Stress macht dumm und krank. Das Konzept Mastery Mode soll die Erlaubnis bereitstellen, souverän und kreativ zu arbeiten, nicht im Akkord, sondern im Sustainable Pace. *_{Das Wort Performance suggeriert, dass alles Handeln auf Optimierung und Leistung zu trimmen ist. Das ist unmenschlich, hässlich und blödsinnig obendrein. Ich möchte in diesem Zusammenhang mit Performance einfach eine Funktion aus Wirkung und Zufriedenheit in Leistungssituationen bezeichnen, denn wenn mich ein schlechtes Ergebnis unzufrieden macht, handelt es sich um eine Leistungssituation, egal, welcher Natur sie ist.} _{PS: Das Foto stellt Master Po dar, den Lehrer von Kung Fu Caine. Das Stereotyp des weisen Lehrers ist als Symbol für Mastery Mode evtl. ein bisschen platt, aber hey, Stereotype funktionieren. Deshalb sind sie ja Stereotype. ;)}

Certified Scrum Product Owner

Sun, 12 Feb 2012 12:03:00 -0700

Das Training bei improuv war wertvoll. Natürlich hat man im Vorfeld viel gelesen und in der Arbeit mit Scrum in Projekten versucht, alles in den Griff zu kriegen. Kriegt man aber nicht. Und in der Schulung erfährt man zwei Dinge: 1. Dass alle anderen dieselben oder noch zusätzlich Probleme haben.
2. Wie man es evtl. doch in den Griff kriegt. Der Grund ist einfach und wurde vom Trainer, Christoph Mathis, auf den Punkt gebracht. Scrum ist 5% Wissen und 95% Mindset. Das Auffälligste fand ich: Ich und Gott sei Dank auch andere fragten immer wieder Dinge in der Form: "Darf ich dies oder jenes machen?" Die Antwort hielt einem oft vor Augen: Man soll nachdenken und sich intelligent verhalten. Und dann ausprobieren. Inspect and adapt. Ich halte mich für gewöhnlich nicht für regelhörig, aber dieses Bedürfnis, ein Set an goldenen Regeln zu bekommen, deren Befolgen die Erfolgsgarantie gibt, sitzt tief. Scrum ist kein solches Regelset. Deshalb ist es ein Framework. Bei TechDivision setzen wir Scrum und Kanban als Agile-Ansätze ein, das ist sehr spannend und zuweilen unterhaltsam. Und es passt gut zu der Entwicklung persönlicher Autonomie und Souveränität, die ich in der Arbeitswelt wünschenswert finde, die man (in DE zumindest, vielleicht überall) aber traditionell oft vermisst. Scrum-Schulungen sind so obszön teuer (sorry) wie viele andere High-Profile-IT-Trainings, evtl. sogar teurer. Aber die Schulung war lehrreich. Allein, wie hochinteressant wir beim Ball Point Game versagt haben, war herrlich. Auch herrlich fand ich, dass wir für die Zertifizierung zum Certified Scrum Product Owner keine Prüfung machen mussten (so wie die ScrumMaster). Und zwar, weil die Scrum Alliance die Prüfung noch nicht fertig hat. Ein Schelm, wer Fieses dabei denkt.

FLOW3 Experience (F3X) - die erste Konferenz zu FLOW3

Mon, 26 Dec 2011 09:22:00 -0700

Die Unterstützung, die ich beim Auf-die-Beine-Stellen der ersten FLOW3 Konferenz erhalte, freut mich ungeheuer. Jürgen Egeling und das Board der TYPO3 Association gaben uns das Logo zur Verwendung frei, nach wenigen Tagen waren alle Premium-Sponsor-Plätze vergeben und ein traumhaftes Speaker-Lineup hat zugesagt. TechDivision, mein Arbeitgeber, gibt mir glücklicherweise die Zeit und Ressourcen, die F3X zu verwirklichen. Es macht großen Spaß, ein solches Event zu planen und zu organisieren und die Ausgangsbedingungen sind ideal: Das Thema ist heiß, die Community gut vernetzt und es gibt noch nichts Vergleichbares. Die Location, das Kesselhaus, ist zudem super. Und auch wer erst mal geschluckt hat, als er nachschaute, wo das eigentlich ist, dieses Kolbermoor/Rosenheim, wird, wenn er erst da ist, begeistert sein, da bin ich sicher. Auf Twitter hab ich z.B. einen Berliner gelesen, der meinte, Rosenheim sei ja wohl extrem dezentral. Mei, das kommt auf die Perspektive an, sag ich mal. ;) Wien und Zürich (München sowieso) etwa sind TYPO3-Metropolen, die deutlich näher Rosenheim liegen als an Berlin. Wie dem auch sei. Also, die ersten Tickets sind verkauft, die ersten Sponsoren gefunden. Anfang Januar wird eine Skype-Konferenz der Speaker stattfinden, um Talks und Programm zu präzisieren. Auch überlegen wir, ob wir zusätzlich zu dem FLOW3-Tagesworkshop von Karsten Dambekalns noch einen zweiten anbieten sollen, wann hat man schon mal so viele FLOW3 Hot Shots auf einem Fleck. Ich hoffe und glaube, dass die F3X im ersten Quartal nach TYPO3 Akademie und T3BOARD das dritte große Event in der TYPO3-Community sein wird. Und, wenn wir die PHP-Entwickler da draußen erreichen, darüber hinaus. Toi toi toi!

Neues TYPO3-Blog: typo3-news.net

Sun, 13 Nov 2011 09:19:00 -0700

Für meinen neuen Arbeitgeber TechDivision habe ich ein TYPO3-Blog gestartet, typo3-news.net. Genauer war es ein Relaunch, weil es das Blog vor circa einem Jahr schon mal gab, es war aber ein wenig verwaist und ich habe gern die Gelegenheit ergriffen, es wiederzubeleben. Im Grunde darf ich es nicht laut sagen, aber dafür bezahlt zu werden, was ich eh gern mache, nämlich über TYPO3 zu bloggen, ist natürlich sehr cool. Auch dabei auf Ressourcen der Firma zurückgreifen zu können, zum Beispiel Grafiker wie D. Galambos, ist toll. Den Joke mit "All your extbase are belong to us" wollte ich schon lang mal unterbringen und mit seiner Grafik ist das gleich viel griffiger. [was soll das mit dem "All your..."?]

Danke an die MTUG
Ich möchte mich an dieser Stelle mal bei der Münchner TYPO3-Usergroup bedanken, namentlich Patrick Lobacher, Peter Kraume und Stefan Busemann, die große Teile der lebendigen und inspirierenden TYPO3-Szene in München möglich gemacht haben und prägen. Ohne sie, behaupte ich einfach, gäbe es kein TYPO3-Camp München, keine so aktive TYPO3- und neuerdings FLOW3-Usergroup und es würde deutlich weniger Spaß machen, sich hier in München mit TYPO3 zu beschäftigen.

Interviews for the win
Das Video-Interview mit Patrick hat viel Spaß gemacht und ich möchte in nächster Zeit mehr solche Interviews führen, es ist einfach eine interessante Art und Weise, Experten-Informationen zu erhalten und darzustellen. Mit Sebastian Kurfürst habe ich zum Beispiel ein Telefoninterview zu Semantic Web geführt, das nach dem (dringend nötigen;) Relaunch mit der neuen Ausgabe Mitte Dezember auf eSTRATEGY erscheinen wird.

Here we go: typo3-news.net
Fazit: Ich steh auf Interviews, natürlich sind sie eine schöne Methode, journalistisch Content zu erzeugen, aber ich finde, sie bringens auch einfach. Und ich freu mich über mein neues Blog, das muss man ja mal sagen dürfen, ich hoffe, dass ich es zum Fliegen bringe. :)

Open Source CMS Marktanteile in Deutschland

Sat, 22 Oct 2011 12:09:00 -0600

Zusammenfassung

Untersucht wurden gut 50.000 .de-Domains.
mit dem Werkzeug whatweb
Ergebnis: Wordpress, TYPO3 und Joomla machen 20% der Websites aus, die anderen genannten CMS haben insg. nur 3% Marktanteil.

In einer kleinen privaten Studie hab ich versucht, zu untersuchen, wie verbreitet Open Source CMS Systeme sind. Als Datenbasis für die Domains habe ich eine Liste verwendet, die 54222 .de-Domains umfasst, es sind die deutschen Top-Sites (aus einer Million weltweiter Sites), die Alexa Ende 2008 veröffentlichte. Nicht ideal, aber ich habe derzeit nichts Besseres zur Verfügung. Diese Domains wurden mit whatweb untersucht, das Systeme anhand von Metatags, Cookies, HTTP-Headern, Backlinks usw. erkennt. Hier die CMS in Reihenfolge der Häufigkeit in meinen Ergebnissen:

Wordpress (8.83%)
TYPO3 (6.86%)
Joomla (4.30%)
Drupal (1.30%)
Contao (0.33%)
PHPNuke (0.23%)
ModX (0.22%)
eZ Publish (0.20%)
Serendipity (0.17%)
MediaWiki (0.15%)
Plone (0.15%)
DotNetNuke (0.08%)
Movable Type (0.08%)
OpenCMS (0.7%)
PHPFusion (.06%)
PostNuke (.05%)
Silverstripe (.05%)
CMS Made simple (.05%)

Insgesamt machen die TOP 3, nämlich Wordpress, TYPO3 und Joomla circa 20% der untersuchten 54222 Websites aus. Nimmt man Drupal hinzu, sind es gut 21% (21.29%). Insgesamt fallen 23% (23.19%) auf alle genannten Systeme, daran sieht man, dass die restlichen verglichen mit den wenigen Top-Kandidaten einen sehr geringen Marktanteil haben. An fünfter Stelle steht Contao, jedoch mit großem Abstand zu Drupal. Einschränkungen
Die Untersuchung hat einige Schwächen, die ich kurz diskutieren will.

Die verwendet Domain-Liste ist von Ende 2008, das heißt, dass das seit Veröffentlichung der Alexa-Liste circa 3 Millionen Domains hinzugekommen sind (basierend darauf, dass im Jahr circa 1 Million neue .de-Domains registriert werden, dazu die denic-Statistiken). Außerdem ist es keine Zufallsstichprobe, weil es sich um die Alexa-Top-Sites handelt, das finde ich persönlich aber in Ordnung, weil mich große/gutbesuchte Websites ohnehin mehr interessieren.

Es gibt keine Garantie dafür, dass ein CMS korrekt erkannt wird. Die Merkmale, anhand derer whatweb ein System identifiziert, lassen sich ausschalten oder ändern, wenn der Webmaster das möchte. Es ist auch unklar, ob die Erkennung, warum auch immer, nicht zufällig über alle System hinweg fehlschlägt, Resultat wäre ein Bias zuungunsten der schlechter erkennbaren Systems. Es wäre sehr aufwendig, festzustellen, ob das so ist.

Fazit

Insgesamt denke ich, dass meine Ergebnisse eine vernünftige Validität haben. Die Zahlen von CMScrawler weichen von meinen etwas ab, evtl. sind sie besser, weil sie über 2 Millionen .de-Domains untersuchen, aber wie die Domain-Liste zustande kommt, konnte ich nicht rausfinden. Es wundert mich, dass Wordpress bei CMScrawler hinter TYPO3 und Joomla liegt. Falls jemand eine vollständige Liste aller .de-Domains hat, freu ich mich, wenn er sie mir zukommen lässt. ;)

JavaScript Konferenz JSconfEU 2011 - ein Bericht

Wed, 05 Oct 2011 13:01:00 -0600

Am Wochenende war in Berlin die europäische JavaScript-Konferenz, die JSConf EU. Ich war schon auf vielen Konferenzen, aber ich muss sagen, das war das geilste Event, auf dem ich bisher war. Der Grund: Die Community-Stimmung. Es ist oft und allerortens die Rede von "Familie", auf BarCamps bis hin zu Microsoft-Events - was die Stimmung und den Umgang miteinander betraf, war die JSConf aber wirklich familiär, wirklich etwas Besonderes. Und das bei weit über 300 Teilnehmern aus - tatsächlich - der ganzen Welt.

Dass die Talks ausgezeichnetes Niveau hatten (weswegen ich teils nichts verstand ;), die Location toll war, das Essen super und die Party am Samstag ein Traum, versteht sich von selbst. Sehr cool fand ich auch die Dauer-Performance, bei der Anna Lena Schiller die Talks grafisch nachvollzog (die Poster wird es lt. Veranstalter später als Hi-Res-Print geben). Meine 5 persönlichen Highlights im Folgenden, und diese Auswahl ist wirklich sehr persönlich.

1. JavaScript, Motherfucker, do you speak it! Ich kannte das T-Shirt schon, auch das werbewirksame Foto, auf dem Douglas Crockford es trägt, aber ich find es immer wieder herrlich, wenn es mir begegnet. Auf der Konf lernte ich Pierre Spring kennen, Urheber und Hersteller, ein herrlicher Typ - Entrepreneur und u.a. Gründer der JS UG Zürich. Er und das T-Shirt haben es echt verdient, leider ist die Schweiz so teuer, dass die Bestellung nach DE nicht grad umsonst ist, aber trotzdem, go ahead, die Sache ist Instant-Kult (hier kommt der Spruch her btw), ein Must Have für den JS Nerd (zum Shop, ich krieg keine Provision!;p).

2. Jed Schmidts Talk über JS Golfing. Ich hatte Jed Schmidt noch nie gehört, er ist ein extrem guter Redner, charismatisch, intelligent, witzig, souverän. Das Projekt 140byt.es ist nicht neu, aber wie und was er vortrug, war super. Ich sprach später mit Martin Kleppe von Ubilabs, der die Nummer 2 in Jets Top-5-Liste von 140-byte-Snippets war (Game of Life), und er bestätigte, man lerne extrem viel durch die Beschränkung, die die 140-Bytes-Regel auferlegt, nicht nur über JS, sondern auch über strukturiertes Vorgehen und Optimierung.

3. The Russian! Die Aktion, die die Leute von Uxebu statt eines Talks veranstalteten: Ein Arduino-gesteuertes Gerät, das aus vier stark alkoholischen Flüssigkeiten einen (grauenhaften) Drink mixt. Der jeweilige Sieger eines 1on1-JavaScript-Battles konnte dem Verlierer per Hex-Code eine möglichst diabolische Mischung bereitstellen, der musste dann trinken. War eine Stunde reiner Spaß!
4. Die Brendan-Mandy-T-Shirt-Story. Es war so: Vor dem allerersten Talk kam eine junge attraktive Amerikanerin im 50s-Stil auf die Bühne und meinte, sie wolle nur schnell verkünden, sie sei ein solch großer Brendan-Eich-Fan und liebe JS usw. Dann begann sie zu singen, einen JavaScript-Song und Loblied auf Brendan (natürlich war sie engagiert). Am Abend zu seinem Talk hatte sich Brendan Eich dann mit Tape auf sein T-Shirt ein "Mandy Fanclub" geklebt. Dieses T-Shirt wurde tags darauf, zum Ende der Konf, spontan versteigert zugunsten eines sozialen Projekts, und es ging für 1500 Euro unter den Hammer. Geile Geschichte.

5. Die Abschluss-Kennote von Chris Williams. Er hatte im Jahr zuvor schon eine legendäre, mitreißende Rede gehalten und er blieb 2011 nichts schuldig. Der Ton war kritischer als 2010, er rief auf zu einer positiven, konstruktiven Haltung in der JS-Community, egal ob zu anderen Sprachen, neuen Sprachen (Dart), Trolls oder der Zusammenarbeit insgesamt, z.B, im MDN. Der Talk ist schwer zusammenzufassen, weil seine intensive Wirkung vor allem von Chris Williams' starker, mitreißender Emotionalität und seiner beeindruckenden Ehrlichkeit und Authentizität ausging. What would you do if you knew you could not fail? Stehende Ovationen, sag ich nur. Ganz großartig.

Abschließend sei gesagt, dass es für Bela Varga und mich ein besonderes Extra-Highlight gab: Fabian Jakobs von Ajax.org/Cloud9 hatte angeregt, dass wir unser neues JavaScript-Magazin Mag.js kurz im Plenum vorstellen und die Veranstalter - Malte Ubl, Jan Lehnardt, Holger Blank - waren einverstanden, vielen Dank noch mal dafür!
Also: Wer sich für JavaScript (auch HTML5, Node.js usw.) interessiert, der muss beinah auf die JSConf, eine inspirierende, spaßige Konferenz. Es ist nicht leicht, eines der knappen Tickets zu kriegen, aber ich sags noch mal: Fahrt hin, geile Sache.

InsideAR – Die Augmented Reality Konferenz

Wed, 28 Sep 2011 01:48:00 -0600

Für die t3n habe ich heute einen Bericht über die Konferenz InsideAR geschrieben, der fünf Gründe nennt, warum AR vielleicht wirklich the next big thing wird, der aber einige meiner weniger opportunen Meinungen verheimlicht, zum Beispiel, dass ich AR für Printmedien blödsinnig finde. Es gibt mehrere AR-Beispielfälle, die in Deutschland für Aufsehen gesorgt haben und dementsprechend auf der Konferenz gefeatured wurden, die ich jedoch nicht im Artikel verwenden wollte. Und zwar, weil ich sie (a) nicht für Augmented Reality halte oder (b) doof finde. Sorry. Die vielzitierte Galileo-Sendung, in der man live einen Quiz machen konnte, wenn man das Smartphone über das Fernsehbild hielt, mag ja innovativ gewesen sein, aber das war m.E. bestenfalls Augmented TV Watching, aber doch nicht Augmented Reality? Ich bin altmodisch, ich finde: Fernseher ist nicht Realität. Es macht mir ein bisschen Angst, wenn andere das nicht so sehen. Mit dem iPad auszugleichen, dass Fernseher heute noch keinen Touchscreen haben, das reicht an Innovationsstärke ungefähr bis ins nächste Jahr.

Und dann die Print-Medien: die berühmte SZ-Magazin-Ausgabe, die Zeitschrift Welt der Wunder, die allerlei 3D-Modelle im Smartphone bietet, der Stern... Ich verstehe Konzept und Strategie hinter diesen Aktionen nicht, die halbtote Printmedienwelt versucht, über AR-Applikationen einen Added Value mit Futurismuseffekt zu bieten,
schön. Mir erschließt sich aber nicht, wozu ich das Printmagazin dann überhaupt noch brauche? Meine Meinung, ganz einfach: Ich brauche es nicht. Das bisschen an Info, das im Heft steht, lässt sich hervorragend webbasiert oder in einer App abbilden, das Geschäftsmodell bedruckten Papiers retten zu wollen, indem man über Mobile Devices Begleitmaterial anbietet, halte ich für völlig absurd. Und zum sang- und klanglosen Untergang verurteilt. Papier hat gegenüber Tablets & Co. einige echte, schöne Vorteile, man spielt sie nicht aus, indem man Tablets & Co. zur Bedingung des vollständigen Magazinerlebnisses macht.

Insgesamt fand ich die InsideAR-Konferenz sehr spannend, je besser (v.a. mobile) Geräte werden, desto tauglicher und alltäglicher werden die AR-Anwendungen. metaio, der Konferenzveranstalter, behauptet, 2014 wird AR auf jedem Smartphone angekommen sein. Am wirkungsvollsten finde ich heutzutage edukative Ansätze, weil man etwa im Museum Muße und Ruhe hat, sich mit dem AR-Layer zu beschäftigen. Und Kunstprojekte, weil Künstler, wie bei der Art Invasion im New Yorker MoMA oder beim 9/11-Memorial-Projekt 110 Stories, AR in einer
Funktion verwenden, die im Gesamtkontext sinnvoll ist, nicht als
Selbstzweck. Das zeigt auch einen soziotechnischen Aspekt: Augmented Reality macht es möglich, öffentliche Räume (zurück) zu erobern. Da kommt noch einiges an Guerilla-Kunst/Marketing/Öffentlichkeit auf uns zu.

Augmented Reality im Museum

> Original-Bericht über die Konferenz InsideAR bei t3n