What Is A Comment?

Ok. From technical perspective, comments aren’t much of an issue, since there’s a number of external providers for commenting, i.e. the popular Disqus. Nonetheless, I wanted to rethink everything on my website. Hence, I chewed on the comment thing as well. After a couple of days, I came to a conclusion I hadn’t thought I’d come to before: Just don’t do it.

Yes, that’s right. No more blog comments on my website. Even more, I’ll remove the blog comments from my old entries as well. The reason is quite simple. On-site comments are simply wrong. From almost any perspective it makes no real sense to me to enable commenting on an article/blog right just where the article is. And to be honest, this conclusion is quite new for me as well. I didn’t care much about it until recently.

The fundamental question for me to be answered was: What is a blog comment? To me, a blog comment is a published opinion or statement regarding the content/topic layed out in the original article. Such a statement must have an author – be it disclosed or undisclosed. As a side note: I never allowed anonymous commenting. But surely, impersonated or fake name commenting is/was possible as well.

As for the activity of commenting, the author writes and publishes her thoughts in the internet. Now hold on for a second and re-read that last sentence again. The important thing to notice is the internet. That’s actually what makes me believe that the entire concept of on-site commenting is wrong. The culture and nature of the internet is distributed and free information. Now, if information is useful or related to some other information, it’s simply interlinked. I’m a firm believer that the concept of linking is crucial for the internet.

I think that instead of posting a comment on the same site where the article resides, the comment actually needs to be published somewhere else on the internet and then interlinked with the original article. This is the natural way of information sharing on the internet. Yes, it’s the culture of the internet. The author can simply post her comment on her own website or blog. Nowadays, it’s just a few clicks to get a free personal blog.

Thinking a little more about the topic, one might inevitably notice that actually there’s a trend towards off-site commenting in recent years. With the rise of the social networks (you know, this Facebook, Twitter and G+ things), sharing links and quick commenting has become both popular and usable. Just post the link of the article or page in question, write your statement and fire off a new conversation.

Moreover, sharing on social networks is beneficiary for all parties involved. Be it the author of the original article, the commenting author, the social network platform, or the readers of the comment embodied as “social network status message”. Perhaps the best thing about it is that the comment (and a potential conversation) about the topic in question is being made intentionally and directed. The author of the comment makes many useful and helpful decisions before sharing her comments.

After it was clear for me that off-site commenting is far better than on-site commenting, I thought about a second, related question. I asked myself: “Why should I limit my readers?”. And of course, that’s a very valid question. Why should I, as author of an article, limit the feedback and conversation possibilities for my readers?

At first sight, I thought that it’s not a good idea to limit feedback channels. Even more, just switching off the comment feature on a blog is – well – quite unnatural, since most of the blogs out there have (excellent) on-site commenting. Additionally, from a open communication perspective, it’s counterintuitive to simply block a communication channel. Especially for someone like me, who really is very dedicated and passionate to develop and foster communication and feedback all the time. However, I finally decided to disable this communication/feedback channel and go for the hard way. The key argument here is based on a very simple idea: Providing a wrong option doesn’t improve anything.

That’s why I’ll no longer provide on-site comments on my website. You can share your feedback with me and others at any time. Write your thoughts on your own website, post your comment on a social network, link to original or related sources and let me know about your comment if you like. You can surely just send me an email as well.

Im Interview: Bettina Ruggeri

Gerade wegen des intensiven Wirkungsspektrums der Rolle ist es mir eine Freude, mit Bettina Ruggeri eine erfahrene Scrum-Masterin für ein Interview gewinnen zu können. Bettina blickt nicht nur auf vielschichtige Erfahrungen als Scrum-Master zurück, sondern ist darüber hinaus eine engagierte Scrum-Masterin, die gerne den Austausch mit Kollegen sucht und das stetige Lernen befürwortet – ja sogar vorlebt. Es folgt ein komprimiertes Gesprächsprotokoll. Viel Spaß!

Hallo Bettina. Was machst Du beruflich?

Aktuell verbreite & lebe ich agile Werte und Methoden als Scrum Master und Kanban Coach. Dazu betreue ich die Ausbildung in unserem Unternehmen und werde vielfach als Moderator eingesetzt.

Darüber hinaus arbeite ich im beruflichen und privaten Umfeld als Konfliktmoderatorin/Mediatorin und begleite Menschen als systemischer Coach.

Welches sind Deine Ziele bei der agilen Software-Entwicklung?

Mein Ziel ist eine verbesserte Zusammenarbeit, um gemeinsam Ziele zu erreichen. Deshalb möchte ich eine Firmenkultur fördern, in der die Interessen aller Mitarbeiter gesehen werden, Freude an Weiterentwicklung und ein wertschätzendes Fehler- und Konfliktverhalten gelebt wird.

Und so konzentriere ich mich immer mehr auf die Menschen, die mir im Leben begegnen – sei es jeder Einzelne, Teams und auch das Management.

Aus meiner Sicht sind Akzeptanz und ein vertrauensvolles Umfeld der notwendige Raum, um Kreativität und Begeisterung für erfolgreiche Produkte zu entwickeln.

Scrum ist mittlerweile das bekannteste und beliebteste agile methodische Vorgehen. Warum?

Nun, es ist in erster Linie natürlich eine vielerorts erfolgreiches agiles Methodenwerk. Darüber hinaus erscheint es dem Neuling bzw. Interessierten auch als ein einfaches Methoenmodell, weil es nur wenige “Regeln” mit sich bringt.

Betrachtet man die Zuneigung zu Scrum etwas genauer, fällt einem schnell auf, das ein Großteil der Vorliebe dem agilen Wert der “Menschenorientierung” zu schulden ist. Scrum stellt den Menschen in den Vordergrund, wie jede andere agile Vorgehensweise auch. Das ist ein Schlüsselfaktor denke ich.

Ist Scrum wirklich so einfach, wie es immer gesagt und vermittelt wird?

Nein, Scrum ist nicht wirklich einfach. Ich denke, Scrum will das auch gar nicht sein. Der “Schein” des einfachen mit den wenigen Rollen, Regeln und Gremien ist zwar da, aber das war’s auch schon. Themen wie Selbstorganisation und Eigeninteresse an Weiterentwicklung sind äußerst schwierig. Sowohl für den Einzelnen, wie auch für die Gemeinschaft.

Ein kurzes Beispiel hilft vielleicht zur Veranschaulichung. In agilen Methoden – so auch in Scrum – gibt es vielschichtige Feedback- und Reflektionsmechanismen. Menschen werden daduch quasi gezwungen, eine Überprüfung der Lage und Ihres Handelns durchzuführen. Das ist schwerer als man denken mag, denn wir Menschen tun uns meist leichter zu sagen, was wir nicht wollen. Doch das zu sagen, was wir stattdessen wollen, ist ungleich schwieriger.

Wieso ist der Scrum-Master für ein Scrum-Team so wichtig? Alle im Team ‘können’ ja Scrum, oder nicht?

Nun, es liegt in der Natur des Menschen, das man in seinem Aufgabenfeld von Zeit zu Zeit in eine gewisse Routine kommt. Dinge, Methoden und Auffassungen schleifen sich ein und der Blick über den Tellerrand fällt dann dem einen oder anderen schwerer.

Ein “frischer Wind” von außen, eine Kraft, die manche steife Blicke wieder aufweitet tut in diesem Moment meines Erachtens gut. Als Scrum-Master erlebe ich mich als die Kraft, die hilft, die gemeinsame Komfort-Zone zu hinterfragen. Insofern kann man sagen, dass es auch eine meiner Aufgaben ist, “unbequem” zu sein. Das Ziel dabei ist die Weiterentwicklung der Arbeitsweisen.

Warum wird oft bei agilen Einführungen der Scrum-Master als neuer ‘Projekt-Manager’ gesehen?

Diese Wahrnehmung hat viele Gründe. Meistens hat es mit der Ab- und Übergabe von Vertrauen und Verantwortung zu tun. Ein klassisches Management ist es gewohnt, Verantwortung explizit an Personen zu übertragen. Es braucht eine Bezugsperson, der sie die Verantwortung buchstäblich ‘in die Hände’ legt.

Manchmal ist es auch etwas banaleres, wie z.B. die nackte Tatsache, dass die völlige Transparenz zwischen Team und Produktverantwortlichen nicht erwünscht ist. Das mag aus vielerlei Motivationsfaktoren entstehen. Entscheidend ist aber meiner Meinung nach, dass man solche Faktoren erkennt. Nur dadurch lässt sich auch ein überlegter Umgang mit der Situation ermöglichen.

Welches sind Deiner Meinung nach die Kern-Eigenschaften eines guten Scrum-Masters?

Die wichtigste Eigenschaft ist sicherlich die “Liebe zu den Menschen”. Als Scrum-Master arbeitet man viel mit und an den Menschen. Da ist es quasi fundamental, den Umgang mit vielerlei Charakteren und Meinungen zu mögen.

Darüber hinaus zeichnet sich ein Scrum-Master für mich durch das leben und vermitteln von Werten wie Akzeptanz, Wertschätzung und Vertrauen aus. Das sind elementare Werte, um den Raum für Kreativität zu schaffen und zu schützen.

In wie weit lässt sich Scrum-Master als Rolle mit disziplinarischer Führung vereinbaren?

Meiner Meinung nach ist das eine Frage der Integration in die Unternehmensorganisation. Natürlich wird auch in die Scrum-Master-Rolle viel Verantwortung “hineininterpretiert”. Das man auch ein ausschlaggebender Faktor sein, muss es aber nicht. Ich denke das mangelnde Vertrauen in das Team ist eher kontraproduktiv. Ich persönlich möchte als Scrum-Master lieber keine disziplinarische Verantwortung übernehmen. Ich denke es wäre für mich und meine Arbeit mit den Menschen eher ein Hindernis als ein Vorteil.

Welches sind die Nachteile der Scrum-Master-Rolle in der Praxis?

Ich glaube das ein Scrum-Master schon vor der Herausforderung steht, sich, seine Aufgaben und seine Rolle jederzeit klar nach außen zu kommunizieren und darzulegen. Der Scrum-Master wird im Alltag meist aus dem Hintergrund agieren und das Team in den Vordergrund stellen. Das ist mit eine der Hauptaufgaben. Schließlich ist die Förderung der Selbst-Organisation des Teams ein wichtiger Eckpfeiler in Scrum.

Daraus kann sich aber auch eine Wahrnehmung Dritter ergeben, die den Scrum-Master als passiv oder so ähnlich empfinden. Eine klare Kommunikation und das ständige Feedback der Mitarbeiter können diesen Wahrnehmungen entgegenwirken.

Was ist für Dich das wichtigste an einem agilen Team?

Die Freude an der Arbeit und an der gemeinsamen Leistung ist sicherlich ein sehr hohes Gut. Das ist natürlich auch eine individuelle Frage der Motivation. Gerade diese Individualität fordert von einem agilen Team eine gesunde Kompromiss- und Konfliktfähigkeit. Besonders die gemeinschaftliche Findung und Beschreitung eines Konsens ist für ein agiles Team von großem Wert.

In diesem Zusammenhang ist es auch wichtig zu erkennen, dass diese Werte nicht einfach “erlangt werden”, sondern von allen stetige Aufmerksamkeit abverlangen. Konsens- und Kompromissfähigkeit ist keine Eigenschaft, sondern ein Ziel, welches jedes Mal angegangen und erarbeitet werden will.

Was fehlt Deiner Meinung nach in der agilen Lebens- und Arbeitsweise?

Ich bin der Überzeugung, dass mangelndes Vertrauen eine große Hürde darstellt. Meine Erfahrung hat mir gezeigt, das gerade diese Öffnung des Einzelnen dem Anderen gegenüber ein großer und schwieriger Schritt ist. Gerade in unserer heutigen Zeit, in der die Professionalisierung mit Klarheit, Sachlichkeit und Nüchternheit assoziiert wird. Vertrauen passt zwar nicht in dieses Bild, aber das liegt nicht am Vertrauen, sondern eben an diesem verzerrten Bild der Professionalität.

Akzeptanz und Wertschätzung sind weitere wichtige Werte, die oftmals – ja sogar in agilen Projekten und Unternehmen – vernachlässigt werden. Hier können und müssen wir dran bleiben.

Wenn Du Dir für die agile Arbeitswelt etwas wünschen könntest, was würdest Du Dir wünschen?

Eine vertrauensvolle und optimistische Firmenkultur, die sich auf die Erreichung der gemeinsamen Ziele konzentriert. Es mag sich etwas abgehoben oder esoterisch anhören, aber es ist durchaus aller Ehren wert, wenn man sich vornimmt, einfach “Licht in die Welt zu tragen”. Manchmal geht uns Menschen der Blick für das große Ganze auch verloren, dann hilft es, sich wieder auf die grundlegenden Dinge zu stützen.

Oft wird z.B. vergessen, dass wir nicht arbeiten, um zu Leben, sondern das die Arbeit Teil unseres Lebens ist. Man kann und sollte nicht einfach 8 oder mehr Stunden seines täglichen Lebens einfach so ausblenden. Das Ziel sollte sein, dass wir als Menschen unsere Arbeit mit Freude erledigen und dass alle Interessen umgesetzt und gelebt werden können. Vertrauen, Akzeptanz, Wertschätzung sind die Kräfte, die uns dabei helfen können.

Vielen Dank, Bettina!

Fazit: Hingehen. Aus gutem Grund.

Mir bleibt nach einem wunderbaren und sehr gelungenen Community-Konferenz-Tag in Nürnberg wieder einmal nur die eine, einzig mögliche Schlußfolgerung: Der .NET Day Franken ist eine Pflichtveranstaltung für die .NET-Software-Entwicklungswelt Süddeutschlands. Das Format, die Verpflegung, die Sprecher, die Themen, die Geselligkeit, die Offenheit, die Location, die Frische. Das alles und vieles mehr spricht für den .NET Day Franken.

Fazit: Hingehen. Aus gutem Grund.

Im Interview: Ole Pophal

In diesem Interview freue ich mich sehr, mit Ole Pophal einen ambitionierten Zeitgenossen gefunden zu haben, der sich den Weg in die Agilität mit Stringenz und Freude gebahnt hat. Im Gespräch mit Ole galt es, die Perspektive sowie den Status Quo der Lehre & Ausbildung von agiler Software-Entwicklung abzuklopfen. Ole ist durch seine jüngsten Erfahrungen im Studium dafür der ideale Gesprächspartner. Es folgt ein komprimiertes Gesprächsprotokoll. Viel Spaß!

Hallo Ole. Was machst Du beruflich?

Ich bin Offizier bei der Bundeswehr und dort derzeit als IT-Koordinator im Bereich IT-Service-Management eingesetzt. Zu meinem Aufgaben gehört dort die Kommunikation von Anforderungen bzw. Problemen zwischen der Bundeswehr und dem (externen) IT-Dienstleister, wie auch die Erarbeitung von Konzepten zum Einsatz der IT in dem mir zugeordneten Teilbereich der Bundeswehr (Organisationsbereich).

Welches sind Deine Ziele bei der agilen Software-Entwicklung?

Ich möchte nach meiner Zeit bei der Bundeswehr (2013) weiterhin im Bereich IT arbeiten. Vermutlich nicht in direkt in der Softwareentwicklung sondern eher an der Schnittstelle “Kunde zu Entwicklung”. Wichtig sind mir hierbei zukünftig Aufgaben, die mir und meinem Team Kreativität und Freiraum bei der Problemlösung ermöglichen.

Wann bist Du mit agiler Software-Entwicklung in Kontakt gekommen und wie?

Mein “Erstkontakt” war im Rahmen meines Studiums, Ende 2010. Es war zugleich das Thema des ersten Vorlesungsmoduls wie auch das angedachte Vorgehen für unser studentisches Entwicklungsprojekt.

Das war Pflichtlektüre für alle Teilnehmer des Studiengangs. Der Studiengang ist vollständig berufsbegleitend für alle Teilnehmer gewesen. In meinem Erststudium (2002–2006) war von agiler Entwicklung noch keine Rede, sondern es wurden eher die klassischen Vorgehensmodelle (Wasserfall, V-Modell) gelehrt.

Das war schon etwas Besonderes für mich, denn offen gesagt habe ich von agilen Methoden vorher nur “so nebenher” etwas gehört. Es mag auch daran liegen, dass ich mich davor berufsbedingt nicht besonders stark mit der Software-Entwicklung auseinandergesetzt habe.

Was ist für Dich das Besondere an der agilen Software-Entwicklung?

Meiner Meinung nach stellt Sie das Individuum wieder mehr in den Mittelpunkt der Entwicklung. Dies betrifft sowohl die starke Orientierung am Kunden, wie auch den einzelnen Entwickler, der in seiner Freiheit und Kreativität – aber auch seiner Verantwortung gestärkt wird.

Das ist z.B. im Vergleich zu klassischen Methoden schon etwas anderes. Ich denke, dass gerade die Orientierung am Wunsch des Kunden durch den klassischen Wasserfallansatz vielleicht nicht immer im Zentrum der Entwicklung stand. Besonders der ständige Abgleich der Entwicklung mit den Wünschen bzw. der Vision des Kunden ist bspw. beim V-Modell in der Art meiner Meinung nach nicht gegeben.

Wie ausgeprägt ist die Ausbildung und Information über Agilität im Studium?

In meinem Erststudium war es de facto nicht vorhanden. Also kann ich eigentlich nur aus der Qualität und Intensität meines zweiten Studiums berichten. Die vermittelten Kenntnisse hängen natürlich stark von der Qualität des Dozenten und dessen Erfahrung mit der Agilität ab.

In meinem Fall wurde ein Scrum-Master als Dozent eingesetzt, der nach Scrum auch in seinem derzeitigen Berufsumfeld entwickelt. Die restlichen Module des Studiums (z.B. Softwarequalität und -test etc.) waren nicht unbedingt auf agile Methoden und Vorgehensweisen ausgerichtet.

Es gehört meiner Meinung nach schon “ein Quentchen Glück” dazu, auch einen kompetenten und erfahrenen Dozenten zu haben. Das wird sicherlich auch von Studiengang zu Studiengang ganz unterschiedlich im Bezug auf Umfang und Qualität sein.

Zu welcher ‘Disziplin’ würdest Du Agilität eher einordnen: Software-Entwicklung oder Organisations-Management?

Ich denke, dass es in beide Bereiche gehört. Wenn ich mich jedoch entscheiden müsste, dann würde ich es persönlich eher dem Organisations-Management zuordnen.

Es gibt in Unternehmen ja bereits den Bereich des “Change und Innovation Management”. Ich denke dort würde es vermutlich am besten hinpassen. Als eigene Disziplin oder Methode ist es mir aus diesem Bereich jedoch nicht bekannt.

Kann man Deiner Meinung nach Agilität überhaupt klassisch didaktisch aufbereiten und lehren?

Ich denke Agilität (im Sinne der mir bekannten Methode zur Softwareentwicklung) setzt neben den passenden Methoden und Werkzeugen vielmehr noch eine entsprechende geistige Haltung voraus.

Damit meine ich eine Bereitschäft für Veränderung und flexibles Reagieren. Ich denke schon, dass es grundsätzlich entsprechend aufbereitet und auch gelehrt werden kann. Ich bin mir jedoch nicht ganz sicher, inwiefern man diese Lehre in bestehende Lehrkonzepte integrieren kann.

Meiner Erfahrung nach Bedarf es dabei aber nicht nur theoretischer Module. Ich hatte z.B. das begleitende Studienprojekt, welches über 1 Jahr parallel zum Studium durchgeführt wurde. Erst im praktischen Vorgehen des Projektes konnte man die theoretischen Inhalte umsetzen und Erfahrungen sammeln, vor allem auch mit den Problemen, die im Zuge dieser Methode natürlich auch entstehen können.

Welche Bestandteile der agilen Software-Entwicklung sind Deiner Meinung nach am schwersten zu vermitteln?

Gerade die “agilen Werte” sind meiner Meinung nach schwer theoretisch zu vermitteln. Hierunter verstehe ich:

• Vertrauen (zwischen Kunde und Entwicklung)
• hohe Kommunikationsbereitschaft
• hohe intrinsische Motivation und Spaß an der Aufgabe
• bestmögliche Lösungen für den Kunden schaffen

Es ist meiner Meinung nach schwer, dieses Wertegerüst der Agilität klar und deutlich zu transportieren.

Was war Dein bisher schönstes Erlebnis in Verbindung mit Agilität?

Das schönste Erlebnis war für mich das gemeinsame Arbeiten mit dem Ergebnis, den Kunden mit seiner eigenen Arbeit komplett zufrieden zu stellen – sogar noch über seine Erwartungen hinaus. Ich denke, dass so eine “Übererfüllung der Aufgabe” nur mit agilen Verfahren möglich ist.

Was ist für Dich das wichtigste an einem agilen Team?

Da gibt es meiner Meinung nach mehrere Punkte. Ich denke dass die richtige Teamgröße und Teamzusammenstellung ein entscheidender Faktor ist. Das Team darf nicht zu groß sein und die Teammitglieder sollten schon mit einer positiven Grundhaltung aufeinander zugehen können.

Besonders wichtig ist für mich die Interdisziplinarität und Besetzung des Teams; also das Prinzip, dass jeder im Team jede Aufgabe durchführen kann. Andernfalls hätte man wieder das Potenzial zur fachlichen Silo-Bildung. Natürlich kann nicht jeder alles gleich gut. Aber dass zumindest jeder im Team jede Aufgabe umsetzen kann ist schon ein wichtiger Bestandteil des Teams für mich.

Was fehlt Deiner Meinung nach in der agilen Lebens- und Arbeitsweise?

Das ist eine schwierige Frage. Ich habe ja nun nicht einen sehr großen Erfahrungsschatz in Punkto Agilität. Ich sehe derzeit keine Mängel in der Methodik oder den Praktiken.

Vielmehr denke ich, dass es im Umfeld der Agilität noch einiges an Nachholbedarf gibt. Damit meine ich größtenteils die Stärkung der Akzeptanz der agilen Software-Entwicklung – sowohl unternehmerisch, als auch gesellschaftlich.

Wenn Du Dir für die agile Arbeitswelt etwas wünschen könntest, was würdest Du Dir wünschen?

Da möchte ich nahtlos an meine vorherige Antwort anknüpfen. Ich denke, dass die Wahrnehmung der agilen Methoden als ernsthaftes Management- und Organisationsmodell noch weiter ausgebaut werden kann und sollte.

Ich würde mir wünschen, dass man diese Anerkennung weiter vorantreibt. Auch durch anpacken von eventuell halbherzigen “pro Forma”-Umsetzungen oder weiteren Entwicklungsbereichen. Ich denke, dass die agile Methodik schon längst aus den Kinderschuhen heraus ist und auch die notwendige fundierte Basis hat, um breite Anerkennung in der IT-Arbeitswelt zu erlangen. Ich wünsche mir sowohl breite als auch tiefe Akzeptanz der Agilität in der IT-Branche.

Vielen Dank, Ole!

Im Interview: Björn Rochel

Es ist mir eine Ehre, den erfahrenen Software-Entwickler und Agilisten Björn Rochel Fragen über das spannende Feld der agilen Software-Ingenieurs-Kunst stellen zu dürfen. Wie kaum ein anderer versteht es Björn technologie- und fachübergreifend im Konzert der professionellen Software-Entwicklung die richtigen Töne mit Gefühl und besonnener Intensität zu treffen. Die komplexe Partitur der Agilität spielt er dabei souverän in unerkannt akribischer Ingenieurs-Manier. Es folgt ein komprimiertes Gesprächsprotokoll. Viel Spaß!

Hallo Björn. Was machst Du beruflich?

Derzeit arbeite ich als Software Engineer für das soziale Netzwerk XING. Mein Team ist verantwortlich für die XING Developer API, die im März als Closed Beta gestartet ist. Davor war ich lange Jahre in unterschiedlichen Rollen (Entwickler, Berater, Architekt) im Microsoft .NET Umfeld tätig.

Welches sind Deine Ziele bei der agilen Software-Entwicklung?

Kurz und knapp: Zufriedene Kunden, erfolgreiche Projekte, technische Exzellenz – und ein harmonisches, zufriedenes Entwicklungsteam. Alles unter einem Hut.

Was zeichnet Deiner Meinung nach einen agilen Entwickler aus?

An erster Stelle steht hier die Eigenschaft des ‘Teamplayers’. Die Kooperationsbereitschaft und -umsetzung ist ein wichtiges Erfolgsrezept für einen agilen Entwickler.

Gleichermaßen zeichnet sich der agile Entwickler durch seine Ansicht aus, dass Software-Entwicklung mehr ist, als einfach nur Code zu schreiben. Es braucht heutzutage eine Vielzahl von weiteren Kenntnissen und Rollen, um eine Software erfolgreich zu gestalten.

Doch das ist nicht alles, denn für mich hat ein agiler Entwickler noch eine weitere Schlüsseleigenschaft. Der agile Entwickler ist sich darüber im Klaren, das Software ständig im Wandel ist und sein wird. Stetige Veränderungsbereitschaft und Lernbereitschaft ist ‘Agilität’ im wahrsten Sinne des Wortes. Ein Design, welches heute gut aussieht und allen Ansprüchen genügt, kann übermorgen schon nicht mehr tragfähig oder adequat werden. Veränderung und Lernen setzt Erkenntnisgewinn voraus. Idealerweise gemeinsam in einem agilen Team.

Kann jeder Entwickler auch ein agiler Entwickler werden?

Natürlich! Ich wüsste nicht, welche Eigenschaften dagegen sprechen würden. Es ist klar, dass sich der eine oder andere leichter oder schwerer tut bei der Entwicklung hin zu einem agilen Entwickler. Wenn die Veränderungsbereitschaft da ist, kann jeder Entwickler ein agiler Entwickler werden. Das sich dabei manche leichter tun – und andere etwas mehr Unterstützung benötigen – das ist ganz normal.

Welche Methoden bzw. Praktiken sind für einen agilen Entwickler unverzichtbar?

Das Thema Testing ist für mich das A und O. Ich persönlich bin ein Freund des TDD (Test-Driven-Design), aber es gibt keinen Anlass für mich, in dieser Sache dogmatisch zu sein. Jeder hat in diesem Punkt seine Vorlieben und persönliche Effizienz. Was hier zählt, ist die Schärfung des Bewußtseins für das Testing. Ergo: wenn es Tests gibt, gibt es einen Ankerpunkt, an dem die agile Entwicklungsweise sich festhalten und orientieren kann. In einfacheren Worten: Ohne Tests kein Sicherheitsnetz. Ohne Sicherheitsnetz ist Software nur schwer evolvierbar.

Guter Punkt. Gibt es denn dann auch so etwas wie agiles Software-Design oder agile Software-Architekturen?

Also ich glaube schon, das ein gewisses Set an Techniken für einen agilen Software-Entwickler hilfreich sein können. Dennoch würde ich aber nicht per se Architekturen oder einzelne Design-Techniken als “agile Architekturen” bezeichnen. Software sollte sich auch an der agilen Prämisse der “Veränderungsbereitschaft” messen lassen können. Dazu gibt es hilfreiche technische Methoden bzw. Prinzipien, wie z.B. lose Kopplung, hohe Kohäsion, S.O.L.I.D. oder BDD (Behavior-Driven-Design).

Agiles Software-Design ist für mich demnach ein Design, welches die Flexibilität und Veränderbarkeit in sich verankert, aber gleichzeitig durch Tests und klare fachliche Umsetzung eine stabile Anwendung ermöglicht.

Viele Entwickler tun sich auf dem Weg zur Agilität schwer. Welchen Rat würdest Du einem Entwickler geben, der sich mit der Adaption der Methode oder Techniken schwer tut?

Puh, das ist eine wirklich schwierige Frage. Ich fange mal mit der methodischen Perspektive an.

Sich stetig einer möglichen Veränderung zu stellen, neue Herangehensweisen zu lernen und dann auch noch auf Anhieb richtig anzuwenden gelingt den wenigsten Software-Entwicklern. Es ist absolut normal, wenn Dinge nicht auf Anhieb klappen. Ergo: Ruhe bewahren. Gute Reflektion und ein stabiler Lernwille helfen. Es gilt: nicht gleich aufgeben, denn schließlich macht erst Übung den Meister.

Aus technischer Perspektive kann ich jedem nur den Rat geben, sich mit Testing als wichtigen Bestandteil intensiv zu beschäftigen. Als konkrete Hilfestellung für die immer wiederkehrende Frage, wie man existierende Software unter Tests bekommt, kann ich hier wärmsten das Buch Working effectively with Legacy Code von Michael Feathers empfehlen. Das war eines der ersten Bücher, die ich zu diesem Thema gelesen habe. Ich profitiere noch heute davon.

Welche Nachteile hat Deiner Meinung nach die agile Vorgehensweise für Entwickler?

Das ist eine persönliche, subjektive Sache. Agile Software-Entwicklung hat eine starke kollaborative und kommunikative Komponente. Insofern ist es für manch einen Entwickler ein Stückweit schwierig – gerade wenn man sich doch eher zurückziehen möchte und eigenständig am Rechner arbeiten möchte. Das kann als Nachteil ausgelegt werden. Ich persönlich habe schon des öfteren Entwickler kennen gelernt, die diesen kommunikativen Entwicklungsstil für sich als Nachteil empfunden haben. Das liegt aber weder daran, dass es objektiv ein Nachteil ist, noch daran, dass der Entwickler dafür generell ungeeignet gewesen wäre. Zumeist sind Unsicherheiten und halbherzige Umsetzungen an solchen Empfindungen mit beteiligt.

Wieso sollte Software agil entwickelt werden und nicht anders?

Agile Software-Entwicklung ist für mich das Prinzip der Veränderungsbereitschaft – ja sogar Veränderungsförderung. In unserer heutigen Gesellschaft verändert sich vieles rasant. Gerade im technologischen Bereich und Leben unserer Gesellschaft ist Bewegung und Veränderung normal. Die agile Software-Entwicklung ist schlichtweg notwendig, um sich mit dieser gesellschaftlichen und technologischen Veränderung bewegen zu können.

Agilität ist darüber hinaus noch mehr. Es ist eine Wertevorstellung, sich der Veränderung effektiv und nachhaltig zuzuwenden. Es geht also nicht nur um Veränderung, sondern auch um Werte, die unsere Informations- und Kreativarbeit mit Nachhaltigkeit und Menschlichkeit ermöglicht.

Was ist für Dich das wichtigste an einem agilen Team?

Das hört sich einfach an, ist es doch meist nicht: ein agiles Team sollte ausgewogen sein. Die Interdisziplinarität ist wichtig, denn es geht um die gemeinsame Umsetzung aller notwendigen Kenntnisse in die Entwicklung. Darüber hinaus zeichnet sich ein agiles Team durch die Motivationskraft des Teams wie auch der einzelnen Mitglieder aus. Die Eigenmotivation des Einzelnen spiegelt sich dann im Team wieder.

Was fehlt Deiner Meinung nach in der agilen Lebens- und Arbeitsweise?

Gute Frage. Die Agilität ist heute an einem Punkt, in dem es sich in unsere Software-Entwicklungs-Branche etabliert. Das ist sehr erfreulich, führt aber auch zu Reibungen und Schwierigkeiten. Dadurch reiben sich nicht nur Unternehmen oder Persönlichkeiten auf, sondern meiner Meinung nach auch die Agilität selbst. Begriffe wie Scrum, Kanban oder XP werden leider zu oft verwässert und verschwommen kommuniziert, aufgefasst oder interpretiert. Das ist für die Agilität leider nicht sehr förderlich.

Ich denke es würde uns gut tun, wenn wir Agilität als Grundlage für Werte und Methoden einer modernen Software-Entwicklung – oder Arbeitsweise – auffassen und nicht zu stark mit Implementierungen wie Scrum oder Kanban koppeln. Damit meine ich keine Entkopplung im Sinne unterschiedlicher Auffassungen, sondern eher eine Entkopplung im Sinne des Agilitätsbegriffes. Einfacher gesagt: Scrum und Kanban sind agile Methoden, aber Agilität definiert sich nicht im Gänze über Scrum oder Kanban.

Wenn Du Dir für die agile Arbeitswelt etwas wünschen könntest, was würdest Du Dir wünschen?

Ich würde mir wünschen, dass die Agile Bewegung nicht nur reduziert wird auf Software-Entwicklungs-Methoden oder Praktiken. Ich empfinde es als besonders wertvoll, dass sich eine Wertekultur um die Agilität entwickelt und auch stark transportiert wird, damit sich diese Werte in verschiedenen Bereichen über verschiedene Wege wiederfinden.

Vielen Dank, Björn!

Im Interview: Kai Simons

Ich freue mich sehr über das Thema des agilen Managements mit einem erfahrenen Agilisten, Coach und Trainer sprechen zu dürfen, der sich schon seit Jahren mit dem Wirkungswechsel von Teamführung und agilem Management intensiv beschäftigt. Kein geringerer als Kai Simons, einer der wenigen deutschsprachigen Management 3.0-Trainer, wird mir in diesem weiteren Interview der Reihe der Agilisten Rede und Antwort stehen. Es folgt ein komprimiertes Gesprächsprotokoll. Viel Spaß!

Hallo Kai! Was machst Du beruflich?

Kai: Ich unterstütze Führungskräfte und Teams auf Ihrem Weg zur Agilität als Coach und Trainer. Meine Kunden sind Unternehmen unterschiedlicher Größe und diverser Branchen – vom Mittelstand bis zum Konzern. Darüber hinaus macht mir Facilitation viel Freude, weswegen ich auch als Moderator gebucht werde.

Mein Motto: “Es ist genug agil für alle da!”

Was sind Deine Ziele, wenn es um Agile Software Entwicklung geht?

Kai: Wenn ein Kunde agil arbeiten will, möchte ich, dass er ein klares Verständnis erlangt, was dies bedeutet. Am liebsten vermittle ich es durch die Anwendung von agilen Methoden und Praktiken selbst, damit erfahrbar und begreifbar wird, wie sich die Arbeit in einem agilen Team anfühlt. Auch wenn ich von meinem Hintergrund in der Softwareentwicklung zu Hause bin, macht mir auch der Transfer in andere Szenarien Spaß. Führungskräfte auf diesem Weg mitzunehmen ist mir wichtig.

Warum ist Deiner Meinung nach agiles Management ein wichtiges Thema?

Kai: Das agile Management – noch genauer das mittlere Management – ist ein entscheidender Faktor in der agilen Organisation. Das mittlere Management stellt die Verbindung zwischen dem Top-Management und Team dar und ist somit ein wichtiges Bindeglied für die strategische und operative Zielorientierung. Für mich geht diese Schlüsselrolle sogar noch ein Stück weiter. Gerade Manager im Team- und Abteilungsbereich übernehmen den Löwenanteil der Verantwortlichkeit für ein agiles Unternehmen. Deren Führungststil beeinflusst direkt die Teams und Mitarbeiter – und damit auch die Wertschöpfung und Produktivitätsleistung.

Ein weiterer wichtiger Aspekt ist die Einführung und Etablierung agiler Verfahren. Die Hauptblocker für agile Einführungen gehören in den Verantwortungsbereich des mittleren Managements. Das ist nicht weiter verwunderlich, zumal sich die ‘klassische’ agile Literatur leider kaum mit dieser Organisationsperspektive auseinandersetzt. Dem können wir entgegenwirken, in dem wir das agile Management als wichtigen und gleichwertigen Grundbaustein der agilen Bewegung etablieren.

Warum hat Management denn so viel mit Agilität zu tun?

Kai: Ganz klar: Agilität braucht Empowerment. Selbstorganisation und Verantwortungsübernahme agiler Teams sind kein Selbstläufer. Gerade diese “neue Freiheit” und das bewußte “loslassen” von Kontroll- und Verbindlichkeitsmechanismen muss durch das Management gefördert werden. Gerade deshalb ist die Rolle und Verantwortung des mittleren Management im Gesamtgefüge sehr wichtig. Das ist kein einfaches Unterfangen und Bedarf großer Zuwendung und Leistung. Hier kommt auch die agile Führung im Sinne der Wertevermittlung ins Spiel.

Guter Stichpunkt. Was ist denn dann das “agile Management”?

Kai: Das agile Management leitet sich durch die Übernahme der Werte und Prinzipen des agilen Manifests ab und bringt diese Werte in den Wirkungsraum der Mitarbeiter- und Organisationsführung. Das mag sich am Anfang etwas abstrakt anhören, ist aber in der Umsetzung durchaus sehr konkret. Als gutes Beispiel kann ich die drei Kernpraktiken der agilen Führung (engl: “Agile Leadership Practices”) anbringen.

1. Aktive Unterstützung der Mitarbeiter in der Organisation
2. Verbesserung des Arbeitsumfeldes der Mitarbeiter
3. Ermöglichen einer stetigen Wertschöpfung für die Sponsoren

Wie hier bei der Führung gibt es konkrete Übersetzungen des agilen Wertesystems in das gesamte Wirkungsfeld des Managements. Doch in letzter Konsequenz ist ein Management ein agiles Management, wenn die Werte und Kultur intuitiv und ganzheitlich adaptiert werden.

Wo liegt der Schwerpunkt des agilen Managers?

Kai: Der agile Manager legt den Schwerpunkt darauf, für die Mitarbeiter und das gemeinsame Ziel “die Bahn frei zu machen”. Das ist eine entscheidende Aufgabenstellung, besonders im Hinblick auf die gesamte agile Organisationsausrichtung. Für den einen oder anderen hört sich das zunächst einmal an wie eine Scrum Master-Aufgabe, der durch Servant Leadership dient und Hindernisse aus dem weg räumt.

Doch diese Sicht wäre hier viel zu einfach, denn während ein Scrum Master sich eher reaktiv zur Problemstellungen verhält, ist der agile Manager proaktiv und betrachtet eine breitere Perspektive. Der agile Manager hat demnach stetig und aktiv die Schaffung und Stabilisierung eines agilen Organisationsrahmens im Blick.

Für den agilen Manager gilt das Motto: “Gutes mehren, Schlechtes wehren!”

Was unterscheidet einen agilen Manager von einem klassischen Manager?

Kai: Das ist eine gute Frage – denn es gibt auch genug “klassische” gute Manager. Man sollte nicht den Fehler begehen, und agile Managementmethoden höher bewerten als die klassischen Vorgehensweisen. Es ist vielmehr eine perspektivische Erweiterung. Die agile “Perspektive” richtet sich deutlich aus an Systemmodellen und Selbstorganisationsprinzipien.

Das agile Management ist stark darauf ausgerichtet, das Team und die gesamte Organisation auf Selbstorganisation auszurichten. Dabei spielen gezielte Delegierung und Verantwortungsdistribution eine wichtige Rolle. Gleichermaßen ist gerade durch diese selbstorganisatorische Ausrichtung eine viel stärkere systemische Betrachtung bei Wertschöpfungs- und Organisationsentscheidungen wichtig.

Wir betrachten Unternehmen im agilen Management als Netzwerke von Individuen, die Wert erschaffen. Dabei hilft uns das Wissen der komplexen adaptiven Systeme.

Guter Punkt. Das bringt mich zum Thema “Management 3.0”. Management 3.0 ist ein Set von konkreten Management-Methodiken. Worum geht es dabei im Allgemeinen?

Kai: Zunächst einmal würde ich Management 3.0 nicht nur auf Methoden reduzieren, obwohl diese sicherlich wichtige Komponenten darstellen. Management 3.0 sind Werte und Methoden für ein Management von agilen Teams und Organisationen. Es geht also um die Theorie, das Mindset – wie auch um die Praktiken. Vereinfacht kann man sagen, Management 3.0 ist die vorhin schon erwähnte agile Perspektive des Managements. Klar aufbereitet und umsetzbar.

Das ist meiner Meinung nach auch eine der Stärken von Management 3.0. Es wird nicht einfach auf die agilen Werte verwiesen oder eine abstrakte Wertevermittlung angestrebt. Vielmehr geht man den Weg der Wertvermittlung durch Anwendung der konkreten Methoden und Praktiken. An Hand von Fallbeispielen werden zunächst die methodischen Werkzeuge für die Praxis angewendet, um auf diesem in einer Metabetrachtung auch die agilen Werte herauszuarbeiten.

Ok. Was ist denn dein “Lieblingswerkzeug” bei Management 3.0?

Kai: Mir gefällt Delegation Poker am meisten, weil es um Erlangung von Vertrauen geht und weil die Reflektionsarbeit dabei sehr ausgeprägt ist. Fragen wie: “Wie weit gebe ich dem Team die Freiheit zur Selbstentscheidung?” und “Wie weit möchte ich bei der Entscheidung beeinflussen?” sind meist Brennpunkte, die ausführlich behandelt werden wollen. Die Diskussionen und Erkenntnisse daraus sind sehr spannend.

Management ist eine wichtige Perspektive im agilen Umfeld. Aber warum ist das Thema “Managment” beim agilen Coaching dann eher im Hintergrund?

Kai: Meiner Meinung nach liegt das an den Wurzeln der Agilität. Die Wurzeln sind nun mal in der Technik – also in der Software-Entwicklung. Die agile Bewegung hat Ihren Ursprung in XP, Crystal, Scrum und ähnlichem. Heute jedoch geht es um mehr als “nur” Technologie. Es geht um agile Organisationen. Gerade deswegen rückt die Management-Perspektive in jüngster Zeit weiter in den Vordergrund.

Das ist ein richtiger und wichtiger Schritt.

Denn: Bis vor einigen Jahren sah das leider etwas düsterer aus. Rund um das Thema “Management” gab es wenig agiles Wissen und Werkzeuge. Mehr noch, es wurde vieles zu unkonstruktiv und stiefmütterlich betrachtet. Ein schönes Beispiel ist hier die mancherorts gehörte, unsägliche Aussage, dass Agilität “kein Management mehr brauche”. Das führte zu Irritationen und auch ein Stückweit zu Fehlentwicklungen.

Doch gerade in letzter Zeit konnten wir konstruktive Lösungen zum Thema Managment und Agilität herausarbeiten. Vielmehr noch, durch den generellen Geist der empirischen Erkenntnis wissen wir, dass diese Lösungen auch funktionieren. Insofern sehe ich einer stärkeren Thematisierung von agilem Management auch sehr positiv entgegen. Das ist für mich eine normale, evolutionäre Entwicklung.

Aus der Praxis: Was ist das erste, was ein agiler Manager Deiner Meinung nach begreifen und umsetzen sollte?

Kai: Ich denke dass es da erstmal keinen großen Unterschied zu agilen Teams gibt. Zunächst geht es um die Schaffung des Grundverständnisses durch die Wissensvermittlung der Methoden. Eine klare Auseinandersetzung mit Zielen, Erwartungen und einer eigenen unternehmerischen Strategie ist für die Adaption agiler Werte auch sehr hilfreich. Damit lässt sich ein klares Bild über Prozessadaption und -Transformation ableiten, denn meistens ist die Wandlung hin zu einer Selbstorganisation ein Weg mit Hindernissen und Unwegbarkeiten.

Hört sich sehr spannend an. Was sollte man bei agilem Management dann unbedingt vermeiden?

Kai: Das mag sich jetzt etwas platt anhören, ist aber wirklich so: Jedes Handeln, welches gegen die agilen Werte verstösst, sollte vermieden werden. Gerade deswegen ist eine Wertevermittlung für uns als agile Coaches so wichtig. Werte sind der innere Kompass bei Situationen, in denen man sich für oder wider eine Maßnahme entscheided.

Es gibt auch durchaus konkrete Gefahren, die man im agilen Management lieber umschiffen sollte. Dazu zählen zum Beispiel indirekte Kommunikation, die Konzentration auf extrinsische Motivationsfaktoren oder aber das Festhalten an Macht und Kontrolle.

Was fehlt Deiner Meinung nach in der agilen Lebens- und Arbeitsweise?

Kai: Sehr gute Frage. Es fehlen meiner Meinung nach ein Stückweit Führungskräfte mit stabiler Vertrauensbasis zu ihren Teams. Gerade wenn Fehler passieren, sollte das Vertrauen weiter aufrecht erhalten werden. Wir stehen hier als agile Bewegung bei manchen, komplexen Umgebungen noch am Anfang. Insofern sind wir als Agilisten auch gefragt, einer Erweiterung der Agilität im Sinne von Leadership und den dazugehörigen Praktiken positiv entgegenzublicken – ja sogar zu fördern.

Weiterhin ist für mich offensichtlich, dass uns derzeit konkrete Antworten für eine fundierte, grundsätzliche Ausbildung fehlen. Damit möchte ich ganz bewußt den Blick in Richtung Hochschulen und Studierende richten. Heutzutage werden – wenn überhaupt – wenig agile Methoden im universitären Umfeld fundiert vermittelt und umgesetzt. Vor allem nicht an Management-Studiengängen.

Ohne Umschweife steht fest: Da sind wir als agile Bewegung defitizär aufgestellt.

Wenn Du Dir für agile Arbeitswelt etwas wünschen könntest, was würdest Du Dir wünschen?

Ich wünsche mir den weiteren Transfer der Konzepte der Agilität in viele verschiedenen Arbeitsbereiche – nicht nur in der Software-Entwicklung oder im IT-Umfeld. Ich bin fest davon überzeugt das auch die agile Bewegung von solch einer Erweiterung profitieren kann. Ein sehr gutes Beispiel ist der Austausch der agilen Bewegung mit SeriousPlay, Service Design Thinking oder Innovation Games. Ich wünsche mir mehr Austausch mit anderen Denk- und Arbeitsmodellen, damit wir als agile Bewegung uns weiter entwickeln und im Ganzen zu einer besseren Arbeitswelt beitragen können.

Vielen Dank, Kai!

Im Interview: Markus Andrezak

Ich bin sehr stolz, den erfahrenen Kanban-Kenner Markus Andrezak für ein Interview über Agilität und Kanban gewinnen zu können. Als weltweit anerkannter Agilist und Kanban-Experte ist er genau der Richtige, um das Zusammenspiel zwischen Kanban und agiler Software-Entwicklung näher zu durchleuchten. Dieses Interview ist das vierte in der Interviewserie der Agilisten. Es folgt ein komprimiertes Gesprächsprotokoll. Viel Spaß!

Hallo Markus. Meine klassische Eingangsfrage: was machst Du beruflich?

Ich war lange im Management des Product Development bei mobile.de für Prozesse und Architektur zuständig, wurde dann Produktchef für die mobilen Produkte (iOS, Android, mobile Portal), werde aber im Mai Produktchef einer anderen Berliner Firma im Web, die ich noch nicht nennen darf.

Ok. Was sind Deine persönlichen Ziele bei der agilen Software-Entwicklung?

Ich will tolle Produkte bauen, die nicht nur in einer Nische ‘funktionieren’ sondern wirklich Breitenbedarf decken und wirklich in der Breite Wert schaffen.

Produkte sind aber nur so toll wie die Leute, die sie bauen. Deshalb ist mir immer wichtig, eine Firmenkultur mit aufzubauen, in denen alle Mitarbeiter sich verwirklichen und stetig weiterentwickeln können. Ich hoffe das klappt dann auch bei mir selbst!

Wie würdest einem Interessierten Kanban in einem Fahrstuhl erklären?

Ich würde sagen, dass man bei Kanban versucht auf sehr natürliche Weise in dem, was man tut, immer besser zu werden. Man versucht das, indem man sein Tun immer künstlich um einen kleinen Tick schwerer macht. Dabei stösst man automatisch immer wieder auf neue Probleme und Herausforderungen – ohne nach ihnen suchen zu müssen. Um einen Nordpol zu haben zu dem man läuft, sagt man: “man will Flow erreichen”.

Den Flow visiert man an, in dem man immer weniger Dinge auf einmal erledigt… was in letzter Konsequenz immer schwerer wird. Am Ende, wo man natürlich nie ankommt, ist dann alles um einen herum viel entspannter, weil das Umfeld bewußt gut beherrscht wird.

Warum ist Software-Kanban denn so anders als das “Original” aus der Automobil-Industrie?

In der Automobil-Branche ist das Ziel grundsätzlich ein Anderes. Dort ist es wichtig, die selben Dinge immer wieder zu produzieren – so gut und effizient wie möglich. Deshalb versucht man hier, die Variabilität aus dem Produktionsprozess herauszutreiben.

Bei uns in der Software-Entwicklung werden neue Dinge geschaffen. Hier besteht gerade der Wert in der Variabilität. Deshalb muss unser Kanban so sein, dass es Variabilität zulässt. Ansonsten würden wir ja immer nur “Copy & Paste” machen – und somit keinen echten Wert generieren. Vorsichtig ausgedrückt: Das wäre ganz schlecht.

Ist Kanban eigentlich agil? Und wenn ja: Wieso?

Tja, wenn ich das so genau wüsste. Offen gesagt, ich weiss nicht einmal genau ob es mich wirklich interessiert.

Ich bin mir ziemlich sicher, dass die Werte des agilen Manifests durchaus von Kanban vertreten werden. Ich würde sogar so weit gehen, dass gerade die Werte von Kanban und Lean es erst zu dem machen, was sie sind. Es geht vor allem um Ganzheitlichkeit, Menschlichkeit, Autonomie und die Veränderung von unten. Das macht es dann auch mit den agilen Werten ein bisschen schwer, weil sie – glaube ich – nur ein Ausschnitt der Kanban und Lean-Werte sind.

Kurzum: Ja, Kanban ist für mich persönlich sehr agil. Sogar noch einen Tick mehr als andere Methoden.

Viele “Kanbanista” preisen Kanban als methodisches Allheilmittel an. Ist es das wirklich?

Das ist zuerst einmal gar nicht meine Wahrnehmung. Für mich ist es so, dass Kanban mir eher “passiert” ist als das ich es “angewendet” hätte. So nehme ich das auch bei anderen Kanban-Teams wahr.

Es gibt ja die alte Diskusssion “Scrum vs. Kanban”, die ein wenig banal und sinnfrei ist. Meine Vermutung für diese z.T. hitzige Diskussion ist, dass in den “Siegeszug von Scrum” nun einmal Kanban als alternative Methodik auftrat und einige, die gerade Scrum adaptieren, sich auf Kanban einlassen und soz. ‘konvertieren’. Doch das nur am Rande.

Tatsächlich haben viele so wie ich mit Kanban die Erfahrung gemacht, Fortschritte machen zu können, die sie vorher nicht realisieren konnten, weil tatsächlich Kanban sich relativ viral über die Erfolge, die man hat, verbreitet.

Ich habe mit einem 3-Mann-Team ganz schüchtern angefangen, um ein ganz konkretes Problem mit Kanban zu lösen. Das haben andere in der Organisation gesehen und den Erfolg natürlich “Schick” gefunden… dann waren es 12… usw. Am Ende hat die ganze Abteilung von 40 Mann mit Kanban gearbeitet, ohne dass ich das großartig gesteuert hätte. Das war einfach eine tolle Erfahrung. Derart viral passiert das auch bei anderen Kanban-Teams.

Also: Erfolgsversprechend? Ja. Allheilmittel? – Nein. Selbstläufer? – Nein.

Was hälst Du von “Personal-Kanban”? Ist das eine Art “Solo-Kanban” für Einzelgänger?

Ich finde Personal-Kanban eine gute Sache, verfolge es aber nicht aktiv oder intensiv. Mir leuchtet es vollkommen ein, dass in dem selbstreflektierten Bereich die Visualisierung mindestens die selbe Kraft hat wie bei uns in der Software-Entwicklung.

Die Visualiserung alleine sind meiner Meinung nach 80% des Geheimnisses, Erfolges und der Kraft von Kanban. WiP limitieren und Pull sind dann noch einmal 10%.

Das genau diese Mittel im kleinen, persönlichen Bereich funktonieren bezweifele ich nicht eine Sekunde. Ich selbst wende es nicht an, weil ich mich gar nicht so sehr meinem Time-Management widmen muss.

Kann jeder Kanban? Anders gefragt: Braucht man Trainer und Coaches, um Kanban anwenden zu können?

Oha! - (kurze Pause) - Ich glaube die Umsetzung von Kanban ohne eine echte, professionelle Einführung ist sehr schwer. Nun, wie man diese Einführung bekommt steht auf einem anderen Blatt. Da kann es besonders unterschiedliche Wege geben.

Nehmen wir mal mein Lieblingsteam in einer Schwesterfirma als Beispiel. Da hat niemand jemals ein Kanbantraining bekommen. Wir haben uns im Sommer auf einer Terasse getroffen, ich habe etwas über Kanban erzählt und Schwupps – wollten sie alle mitmachen.

Sie waren so motiviert, ich musste nur ein paar Mal zu Beginn “dabei sein” und der Rest geschah in kompletter Eigenregie. Das Schöne: Es lief quasi Lehrbuchmäßig! Das ging so weit, dass alle Vorhersagen bzgl. Leadtime und Verringerung der Standardabweichung von Leadtime eintrafen. Auch die Qualität des Codes ist dabei unglaublich gestiegen.

Für mich steht fest: Man kann sich Kanban-Wissen auf ganz viele Arten aneignen. Aber: ohne eine gewisse Grundausbildung ist es schon schwer, den Geist und die Werte leben zu können – und das nachhaltig. Ansonsten wäre die Gefahr des “Slide-Back”-Effektes doch ziemlich hoch.

Kanban wird oft sehr mechanisch beschrieben. Welche essentiellen Werte hat die Kanbankultur?

Ooh. Ja. Das Gerücht der “mechanischen Beschreibung” ist mir auch schon zu Ohren gekommen. Bis heute ist mir nicht klar, wie es dazu kommen kann. Gehen wir mal vom Schlimmsten aus. Stellen wir uns vor, wir wären gar nicht bei uns, in der relativ netten Software-Industrie. Nehmen wir an, wir sind bei Toyota. Dann würden wir erst mal irgendeines der Bücher von Ohno nehmen, um zu verstehen, was die Werte sind.

Und dann – die Überraschung. Da strotzt es nur so von Menschlichkeit, Autonomie, Selbstverwirklichung, ständiger Veränderung, stetiger Verbesseung – und zwar von unten getrieben. Man begegnet dem Manager, der auf dem Gemba lernt und seinen Mitarbeitern mit Respekt begegnen muss, um von ihnen ihre Probleme zu lernen.

Man kann auch Toyota Kata lesen um zu sehen, wie geschickt Toyota einen kleinen Trick einsetzt um eben auf jeder Ebene – von der Strategie, über die Produktentwicklung, bis zur Produktion – immer besser zu werden. Immer getrieben davon, als Firma agil und beweglich zu bleiben. Einen guten, sicheren, angenehmen Arbeitsplatz und tolle Produkte zu bieten. Das ist genau die Ebene, auf der wir die Werte übernehmen.

Welches ist der größte unternehmerische bzw. organisatorische Mehrwert von Kanban?

Der Wohl größte Benefit ist dieser unscheinbare, kleine Schalter im Kopf eines jeden im Unternehmen, der mit Kanban umgelegt wird. Es ist der Schalter, der uns als einzelne an die gemeinsame Arbeit und das gemeinsame Ziel blicken lässt. Es ist der Schalter, der den Fokus auf den eigentlichen produktiven Mehrwert legt.

Das ist das Besondere an Kanban: die ganzheitliche Fokussierung auf den Value Stream von allen Beteiligten.

Woran kann Deiner Meinung nach Kanban in einer Organisation scheitern?

Es ist ja in den vorangegangenen Antworten schon durchgeklungen, dass ein großer Erfolgsfaktor von Kanban die Kultur und die damit verknüpften Werte sind. Fehlt das Werteverständnis, so fehlt auch die Fähigkeit der Entfaltung der Autonomie oder das effektive Delegieren. Ein weiterer Risikofaktor ist sicherlich auch eine mangelnde Objektivität im Umgang mit der Arbeit und den Aufgaben. Es ist besonders wichtig, in Sachfragen die Sachlichkeit im Auge zu behalten.

Das führt mich gleich zur Minderung dieses Risikofaktors: Es ist absolut essentiell, durch eine stringente Umsetzung und objektive, belegte Fakten ein Grundvertrauen in die gemeinschaftliche Aufgabenstellung bzw. Arbeitsweise zu etablieren.

Fakten schaffen Vertrauen.

Ein Rückfall zu den altgedienten und spekulativen “Versprechungen” über Leistung oder Lieferung kann an einem einzigen Augenblick monatelang aufgebautes Vertrauen vernichten.

Versprechungen schaffen Mißtrauen.

Was wäre Dein Wunsch für die zukünftige, moderne Software-Entwicklung?

Ich denke uns allen wäre schon ein großes Stück geholfen, wenn es weniger von diesen unnötigen Territorial-Kämpfen geben würde. Agil oder nicht agil, Scrum oder Kanban, Java oder Scala, Emacs oder Vim – das alles muss nicht sein. Es ist schon verblüffend, wie irrational so ein ganz und gar “rationaler Berufsstand” wie der der Software-Entwickler sein kann. Gut – wir sind alle nur Menschen. Aber – wir sind auch Ingenieure.

Mein wichtigster Punkt dabei: Ich wünsche mir weniger Anekdoten und mehr Analytik. Es ist frappierend, wie heute z.T. Software entwickelt wird. Da werden Mutmaßungen über Vorgehensweisen und Konsequenzen gemacht und zu viel zu vielen Fragestellungen einfach nur vage Aussagen in den Raum geworfen.

Mehr Analytik und mehr Fakten – das bringt uns weiter.

Vielen Dank, Markus!

E4X: Embedded XML Language

E4X is short for ECMAScript for XML and is a very nice JS embedded XML processing language. I used it for my data processing and visualization project a few years ago with XULRunner and it turned out to be an indispensible tool for XML/XHTML processing.

Let’s see how E4X looks like:

var c = <customers>
  <customer name="ACME Corp." id="3" type="Supplier">
    <contact>Mr. Doe</contact>
    <offer count="5" amount="60000" />
  </customer>
  <customer name="YooRoo Ltd." id="7" type="Engineer">
    <contact>Senor DeLa Soul</contact>
    <offer count="6" amount="120000" />
  </customer>
  <customer name="Rock-A-Fella" id="21" type="Supplier">
    <contact>Mr. DeLa Rocka</contact>
    <offer count="7" amount="110000" />
  </customer>
</customers>;

Yes, it’s that easy. customers now is a full XML object. No big string play is involved, just start typing your XML and you’re fine. But wait, there’s a lot more to come. Let’s see how we can access all <contact> nodes of our <customer>s:

var contacts = c.customer.contact;

And if you were to select the names of our customers instead we can use the attribute accessor syntax:

var names = c.customer.@name;

Isn’t this incredibly simple? It is. Now let’s get to the interesting features. One of the features I used most is the great and easy to apply filters feature. A filter is an expression enclosed in braces (). Say you only want the <contact>s of customers of type Supplier:

var supps = c.customer.(@type=="Supplier").contact;

We could even dive into a subtree, filter on any data and return some attribute on the higher tree nodes. You want to know the name of the customers whose offer amount is below 100000? Nothing easier than that:

var loperfs = c.customer.(offer.@amount<100000).@name;

But wait! The filter feature I used at most is yet to come. The great thing about E4X filters actually is that you can effectively use any JS function to perform your filtering:

var onlyvip = function(x){
  return x.search(/dela/i) > -1;
};

var vips = c.customer.(onlyvip(contact)).@name;

Voilà. For me, the ability to filter with arbitrary JS expressions and embed them right into my XML node selection turned out to be a very powerful and useful feature.

There’s a lot more useful things on E4X to explore, but I finally want to introduce you to another cool feature I (sadly) discovered very late. If you quickly want to build up an XML from data, you can use the powerful interpolation feature. Just enclose your variable or expression into curly braces {} within the XML literal. Sounds nice? Just judge for yourself:

var watches = [{
  name:"longines", 
  price:15000
},{
  name:"icw",
  price:20000
},{
  name:"rolex",
  price:25000
}];

var to_euro = function(x){
  return x/2;
};

var xml = <watches/>;

for each (var w in watches){
  xml.watch += <watch 
    name={w.name} 
    price={to_euro(w.price)}
  />;
}

console.log(xml.toString());
/* 
Output:

  <watches>
    <watch name="longines" price="7500"/>
    <watch name="icw" price="10000"/>
    <watch name="rolex" price="12500"/>
  </watches>

E4X FTW! 
*/

PS: You can guess from my official dislike of Googles V8 JS engine that E4X isn’t implemented in V8 (and consequently doesn’t exist for node.js). Apart from SpiderMonkey, Rhino and AS3 have E4X suppport. Oh, E4X is an official ECMA Standard, by the way.

Generator Expressions

One of those little known innovations surely is the development of the JavaScript language itself. Since I had to dive in a little deeper into JS last summer for a small project, I discovered some neat features I wasn’t aware of. One of those features is called generator expressions.

The python people now surely know what this trickshot is going to be. Generator expressions are a nice way of creating sequences and even do some mapping and filtering on them. Before we look at generator expressions, let’s first build up a small range generator with the yield feature:

var range = function(s,e){
  for (var i=s;i<=e;i++) yield i;
};

Now that we have a simple range sequence generator using yield, we could just iterate over it and display the sequence:

for (var i in range(1,15))
  console.log(i);

Good thing. Now, if we’d like to materialize the sequence of range(1,15), we could preinitialize an array and just push the values into the array instead of logging. Something similar to this:

var a = [];
for (var i in range(1,15))
  a.push(i);

Looks fairly straight-forward. However, we could materialize our range much easier by using array comprehensions:

var a = [i for (i in range(1,15))];

This is much better. Simple, terse, readable. Array comprehensions even allow us to modify and filter the materialization on the fly easily. Say you want the square of all evens from our list. Piece of cake with array comprehension syntax:

var a = [i*i for (i in range(1,15) if (i%2==0)];

Nice. Now let’s finally get to the feature we were looking at from the beginning: generator expressions. Generator expressions are very similar to array comprehensions. The important difference between both is that generator expressions don’t materialize to arrays. This is a very powerful feature since it allows us to write space and time-saving code.

Let’s make another little example for illustration. We want to compute the square and the factorial for the evens of a specific range. We can define this easily with generator expressions:

var fac = function(x) x>1 ? x*fac(x-1) : x;

var squares = (i*i for (i in range(1,50) if (i%2==0));
var facs = (fac(i) for (i in range(1,50) if (i%2==0));

The squares and facs definitions look much like array comprehensions, except we used braces instead of square brackets. The real difference however is that both squares and facs are no arrays but real generators.

This means that effectively no square or factorial is being calculated in the above example. The first calculation occurs when the first value of square or facs is being requested. Again, this is no news for people from python land and the C# lovers out there can easily think of generator expressions as a simplified LINQ .Where() and .Select() syntax.

JavaScript Innovation Land

I think the above examples show how new language features can help to write better - that’s more powerful and readable - code in JavaScript. Actually, these language innovations are only one perspective on how many wonderful things happen in JS land. I for one have a solid impression that it’s at least very unfortunate that node.js bigots and unreasonable hysteria on the ‘server-side JS revolution’ obliterate many thoughtful innovations.

I’m well aware that above “trickshot” could surely reraise the old ECMAScript is no JavaScript discussion for a few JS devs outs there. Yes, the above language actually is JavaScript. And yes, I’m aware it only runs on Mozilla, although some of the above features are in ES.Next. My intention surely is not to fire up such a discussion but instead show this specific field of innovation in JavaScript ecospace as an example to the many cool things happening nowadays regarding JavaScript.