Entgegen der nun vielleicht offensichtlich erscheinenden Frage um Frameworks, Testrunner und co. haben wir uns im Dojo auf die "wesentlichen" Dinge konzentriert. Zwar haben wir auch über ReSharper, MSpec, FakeItEasy, NCrunch und NSub geredet, aber wir sind schnell von diesem üblichen Diskussionstrampelpfad wieder runter. Statt dessen wollten wir per Code Kata drei weitere "Werkzeuge" probieren, die uns als essentielles Rüstzeug für TDD erschienen.

Nach kurzer Diskussion standen Kata, Modus, und die 3 Rundenversuche fest: Wir würden die beliebte KataFizzBuzz im Randori mit 4 Teams über 3 Runden a 30 Minuten angehen. Pro Runde galt dabei die Fokussierung an eines der "Pro Tools". Die Runden-Themen waren:

• Merciless Refactoring
• Pen and Paper
• No Runner

Merciless Refactoring

In der ersten Runde ging es um das Werkzeug schlechthin: gnadenloses Refactoring. Im TDD-Alltag wird zwar oft Refactoring betrieben - aber meist nicht gnadenlos. Ich persönlich schaffe es im Alltag sehr selten, wirklich gnadenloses Refactoring umzusetzen. Umso mehr ist das ein Grund, die Gnadenlosigkeit in jedem TDD-Cycle zu üben.

Das frappierende an diesem so "offensichtlichen" und eigentlich eher als methodisches Konzept auszulegenden Tools ist: Es ist unfassbar einfach und schwer zur gleichen Zeit. Das rigorose, bis zur "Sinnlosigkeit" betriebene Refactoring zwingt einen, die Konzentration zum Lesen des Codes sehr hoch zu halten. Ich schaffe es derzeit kaum, wirklich ernsthaft mehr als eine Stunde Vollgas-Refactoring während des TDD zu betreiben.

Interessanter Weise liegt das nur zu einem geringen Teil am eingesetzten elektronischen Helfer. Während ich für ein Rename z.B. in VIM stark mit Regular Expressions arbeite, habe ich für Visual Studio die F2-Taste oder eben den schnellen Resharper-Rename. Natürlich macht mich die eine oder andere Vorgehensweise in der Umsetzung schneller - aber das eigentlich schwere ist für mich nicht die Geschwindigkeit der Umsetzung, sondern die Konsequenz der Umsetzung.

Pen and Paper

Der zweite Versuch zur Erkundung von hilfreichen Tools ist nicht minder ungewöhnlich und interessant als der erste. Nun ging es darum, während des TDD-Zyklusses (Red-Green-Blue) nach jedem Zyklus absichtlich den Zyklus zu "pausieren" und sich kurz dem klassischen Werkzeug Stift und Papier zuzuwenden.

Nach jedem Zyklus wird die Aufmerksamkeit also kurz wieder auf die nebenliegenden Notizen gelenkt. Man kann dort z.B. eine Design-Visualisierung skizzieren, ein paar Optionen oder To-Do's vermerken, sich die Liste alle Domänen-Begriffe nochmals vor Augen halten, oder aber auch ganz lapidar Spezifikations-Texte für Tests ausprobieren.

Das interessante an diesem "Tool" ist, dass es die Stringenz des TDD fördern kann. Obgleich es auf den ersten Blick eher als Ablenkung wahrgenommen wird, kann ein gut ausgenutzter Notizzettel viele hilfreiche Hinweise geben. Besonders, wenn man sich mit einer komplexen Domäne beschäftigt, oder aber per Pair Programming längere Zeit an einem Feature arbeitet, können Papier und Bleistift nicht nur zu Freunden, sondern auch zu echten Helfern werden.

No Runner

In der letzten Versuchsrunde - an der ich persönlich leider nicht teilnehmen konnte - war endlich auch ein technisches Tool im Fokus. Der beliebte und oft heiss diskutierte Test Runner rückte in den Vordergrund unserer Testreihe. Sinn dieser Übung war es, durch den Verzicht herauszufinden, wie "schwerwiegend" denn das Tool Test-Runner sich auf das TDD auswirkt.

Es galt also, FizzBuzz komplett ohne einen Test-Runner in TDD zu entwickeln. Statt also einen Test-Runner und damit auch ein Test-Framework zu verwenden, musste man kreativ und mit minimalem Aufwand sich aus den Bordmitteln der Programmiersprache selbst Tests zusammenschustern. Die müssen dann natürlich ausgeführt werden und die wichtigsten Signale wie "Rot" (Test fehlgeschlagen) und "Grün" (Test erfolgreich) zurückliefern können.

Wenn man das - auch ruhig mal in C# oder Java - ausprobiert hat, stellt man schnell fest, das so ein Test-Runner für eine "kleine Session" gar nicht so entscheidend ist. Natürlich ist es aufwendiger - gerade wenn man dann auch noch Mocks selber zusammenschreibt - aber bedeutend "schlechter" wird die TDD-Erfahrung dadurch nicht. Ganz im Gegenteil: man wird oft kreativer und baut sich schnell sehr treffende Should()-Extensions oder Given()-Factories zusammen.

Fazit

Alles in Allem kann man sagen: Wenn man im Alltag professionell TDD umsetzt, spielt das klassische, technische "Tooling" eine nicht so prominente Rolle wie man es vielleicht vermuten mag. Vielmehr sind es die methodischen Werkzeuge, die die Professionalität in Puncto Qualität und Geschwindigkeit potenziell steigern können.

Gerade vor diesem Hintergrund ist es richtig und wichtig, immer weiter an den methodischen Elementen des TDD zu arbeiten und zu üben.

Today, I want to reflect my perception and opinion about an attitude from the indian culture called Chalta Hai. Before I get into what "Chalta Hai" is and how I see Chalta Hai to be, I want to tell you my story on how I came in contact with this attitude. Naturally, my first contact with Chalta Hai was in an international project with great collegues from India. By that time - around 2010 - I didn't knew anything about this attitude and naturally couldn't name it. However, I somehow "felt" that in certain situations my indian collegues were behaving different than what I was used to.

Three years later I had the chance to be part of an international project with a global, distributed team again. And again I got great teammates from India. And again I found myself wondering about the "coolness" of some of our indian collegues. Luckily, I got the chance to have a chat about this coolness with a nice and smart indian guy on my project.

While we were relaxing from the mental marathon of the meeting with a cup of tea, we came to discuss exactly this thing I was perceiving as "coolness" of my indian teammates. As I was asking how on earth they can stay calm and cool in critical situations where pressure and even insults are being throwed on their faces, my smart indian friend just smiled back to me and answered: "It's chalta hai, my friend".

What Is Chalta Hai?

He continued to explain to me that Chalta Hai is an internal, deeply rooted attribute of the indian culture of living. It stems from Buddhism in a certain sense, as he started to detail it out. If one were to translate "chalta hai" from hindi language, it would more or less translate to "it moves".

Chalta Hai means it moves.

It moves? Yes, it moves. In such a sense, that the world keeps moving around. That whatever happens, it will be over and let another thing happen. In a sense that the past is past and the present is the thing we refer to as the "flow of time". Well, you know, it moves.

The interesting thing is, that Chalta Hai is being perceived and referred to as a negative, more or less counter-productive attidute in contemporary indian living. As for the business perspective, Chalta Hai is being criticised as a "No-No".

Most Indians claim that it substantially hinders the indian economy to deliver innovation and leading-edge performance. Just because of the fact, that Chalta Hai raises a sort of agnostic view to the outcome of any activity. Indians refer to this as a kind of "whatever comes, whatever goes" feeling. Something like we in Europe more or less get a notion of when we are listening to Reggae music while looking to a colourful Bob Marley poster.

But as it turns out with so many things in life, it's not as simple as that. Chalta Hai seems not to be only this one-dimensional thinking of "whatever happens will happen". It seems not only to favor the inability to seriously commit to any goal or target. Chalta Hai seems to be different. At least as I have been told to from my indian collegues.

In its root, ancient sense, Chalta Hai takes care about the soul and inner balance. It does not foster agnostic behaviour, but sharpens the mental sensory for self-destructive thinking. This further explanation reveals an important aspect of Chalta Hai to me:

Chalta Hai does not want to limit the future, but wants to limit the past.

In plain words: Chalta Hai is a relaxing attitude towards what already has happened, not towards what happens or is about to happen. However, one might then think of this attitude to embrace irresponsibility. Interestingly, even most indians think that way. They argue that constantly referring to "Chalta Hai" results in irresponsibility. While this certainly is true to some extent, that again does not seem to be the whole story.

Don't Relax, Do Refocus

As I onderstood from my indian collegues, Chalta Hai - in the core buddhistic sense - is to protect you from psychological distress. It reminds you to take care of your emotional landscape and strive not to expand your emotions too far for all the things that already have happened.

As I listened to this detail of the explanation, I immediately thought of the "Don't take care about the past, take care about today" kind of feeling. I felt like Chalta Hai is like a personal mental note: The only thing connecting the past to the future is what we are doing, not what we did or what we plan to do.

"You're quite close to chalta hai" my teammate responded as I rephrased my thoughts and opinions about what I have been told so far about it. "It has certainly a negative impact as well", he continued, "in such a way, as it is a very easy hide-out to not reflect upon what has happened." That made sense to me.

"However, it merely wants to guide your attention to the future and the power you have. It wants to amplify your forward-thinking. It's more like keep it moving than remain in feelings".

"Ok", I thought to myself. While Chalta Hai wants to empower activity and a progessive way of life, it often causes the opposite. People more often seem to refer to Chalta Hai when they want to say "relax, no stress whatsoever" instead of using it for "let's refocus on what we can do".

One-To-Many Problem

Nonetheless, this seems to be a critical problem in social life of India. I totally understand that indians want to ban "Chalta Hai" from society when it is used to "relax the past" only. Like if someone does harm to others or some other cruelty like natural hazards become true. This is serious and needs to be reflected upon seriously. It doesn't help anyone if happenings are "relaxed" without any other notion of consequence. However, as I have been told Chalta Hai to be, it's Chalta Hai that tells us not only to reflect upon what has happened, but take action as well.

To be frank, most of the time Chalta Hai is perceived to have a negative impact to the society. That's quite reasonable, since Chalta Hai only addresses the "mental well-being" of yourself, not the overall society you're living in. What that means is that while Chalta Hai might resolve your inner distress, it may not be able to resolve the distress of a group. Even if everyone in that group is responding to Chalta Hai for themselves, the overall distress may remain or even might be amplified.

This is a very common problem to what I personally like to refer to as "One-To-Many-Problem". It's not limited to Chalta Hai, but obviously is present in this type of thinking as well. Interestingly, this problematic effect is ready to be observed in a number of examples in indian social life. Your Chalta Hai is not mine, my Chalta Hai is not yours. This space of individuality is inherent to Chalta Hai, but limits its power as well.

The Cosmopolitan Way

Well, although I never lived in indian society nor have had the chance to have a stay in India for a substantially long period, I think I can have my own opinion about Chalta Hai. It's certainly very different from what it's supposed to be. Even more, it's surely very different to the Chalta Hai being lived in India right now. Hence, I want to differentiate my perspective by calling it "the cosmopolitan chalta hai".

My cosmopolitan Chalta Hai has an emphasis on the aspect of movement. I see Chalta Hai to be more a driver for activity, while it certainly keeps to send me a little message of the discontinuation of the past in the background. Even more, I don't want to be reminded too often to Chalta Hai.

My Chalta Hai wants to be in place in case of great or unexpected emotional distress. My Chalta Hai wants to be there whenever critical or shocking situations are going to be faced. Hence, my Chalta Hai is not an everyday attitude. No, it's something I don't want to be reminded to in my everyday life. However, I feel safe and sound to have my personal attitude of Chalta Hai in my back. It will remind me to keep on moving, no matter what happens.

Apart of that, I wish that this deeply rooted Chalta Hai-attitude in India will not be taken as an excuse for inactivity, imperfertedness, or inequality. I hope that the indian culture can take their own roots to reflect upon and act towards the positive and progressive kind of living.

Enough of that. Let's talk about programming languages. In C#, there's no out of the box support for multiple inheritance. Let's not dig into the details on why that is. With C# 3.0 and the landing of extension methods, the disadvantages of not having multiple inheritance have been cirumvented in a certain sense.

With extension methods, one can easily add or overload functionality to existing types. This brings a couple of great advantages, as it equally brings a few challenges as well.

I've been thinking about multiple inheritance in C# and possible everyday usage of mixins already. I've been using it quite often within last 2 years.

Most of the time, I was very lucky to have mixins at hand when I was testing legacy code or dealing with legacy code. In the end, mixins (and extension methods) in C# are about enriching existing code. Sometimes, I found mixins useful for transitions as well.

Let's change static things

When it comes to legacy code, I like to use a pattern I refer to as marker mixin. It doesn't have much in common with marker interfaces, although I must admit that I thought about them while using marker mixins.

A marker mixin typically is a (static) field of a class, decorating the original field type signature, and potentially altering behavior.

I personally use marker mixins very often when it comes to legacy code where a lot of static fields, static class methods or singletons are being used. It's a sensible strategy for me to safe-guard the code back with tests, while not changing too much of its structure beforehand.

Enough babbling. Let's walk the talk with a simple example. Imagine the following existing code:

class MainClass {
  public static void Main(string[] args) {
    Console.WriteLine("Hello!");

    var d = new Dog();
    d.Bark();

    Console.WriteLine("Bye!");
    Console.ReadKey();
  }
}

public class Dog {
  public void Bark() {
    Console.WriteLine("Bark!");
  }
}

Looks quite straight forward. Now imagine following scenario: You need to change the behavior of this code. The MainClass spits out messages the user does no longer want to see. How can you accomplish this task with a minimum impact on the existing code?

The answer obviously is: marker mixins. With a marker mixin, we can change the behavior of the entire MainClass with just one single line of code:

class MainClass {
  static ConsoleBehavior Console;

  public static void Main(string[] args) {
    Console.WriteLine("Hello!");

    var d = new Dog();
    d.Bark();

    Console.WriteLine("Bye!");
    Console.ReadKey();
  }
}

Spot the difference? Yes, it's the ConsoleBehavior field. This field basically is what I am talking about the whole time: the marker mixin. Only by adding the field, the behavior of the Console methods changed. Ok, now this is not really a game changer. Let's look at the implementation of ConsoleBehavior:

public interface ConsoleBehavior {}

public static class ConsoleAction {
  public static void WriteLine(
    this ConsoleBehavior consoler, 
    string output) {
    /* don't do anything */
  }

public static void ReadKey(
  this ConsoleBehavior consoler) {
    Console.ReadKey();
  }
}

Hopefully now the mixin part of the pattern is a little more obvious. The ConsoleBehavior itself is really a marker interface to the extension methods from ConsoleAction. In this case, they selectively change the behavior of WriteLine, while keeping ReadKey intact.

To me, the benefit actually is twofold: first, the extension methods layer the usage (and the usage change) transparently. They can be tested (even TDD'ed) quite easily. Most of the time, I TDD those extension methods to document the behavioral change I'm going to introduce to the legacy component.

Second, I'm now able to selectively change the behavior of MainClass easily. I could revert it back to its initial behavior with other extension methods to ConsoleBehavior and linking them from another assembly, for instance. Surprisingly, I use this possibility more often than I ever thought I would use. It's a very powerful thing to change parts of the cross-cutting infrastructure just with a single assembly reference.

Now, in the end, this marker mixin thing is nothing really special. However, it shows how powerful mixin strategies and extension methods can be in everyday C# programming. I for one solved a couple of challenges with this type of thinking and design. Especially when it comes to legacy code, mixin strategies are a great way to gradually enhance the code using small and approachable steps.

Ich will jetzt nicht eine tiefgründige philosophische Abhandlung vom Zaun brechen, aber es ist meiner Meinung nach sicher lohnenswert, sich ein paar Gedanken über die Verbesserung an und für sich zu machen.

So lässt sich zunächst einmal festhalten, daß die Verbesserung ja ein Ergebnis einer Aktivität darstellen möchte. Sie ist quasi das Resultat dessen, welches wir im Allgemeinen als "verbessern" bezeichnen. Eine solche Handlung wiederum verlangt von uns einen Ausgangs- und Zielpunkt. Natürlich unterstelle ich damit ein gerichtetes und bewußtes Handeln. Das soll uns aber im Weiteren nicht stören.

Nun, wenn wir also verbessern, dann meinen wir damit eine Aktvität, deren Ergebnis wir als positiv einschätzen. Besser gesagt: wir bewerten das Ziel des Handelns als positiver als die gegenwärtige Ausgangslage.

Damit ist auch schon das grundlegende Wesen der Verbesserung umschrieben:

Verbesserung ist eine positive Bewertung einer Veränderung.

Obwohl diese lapidare Definition etwas schmalbrüstig daherzukommen scheint, steckt doch einiges an Aussagekraft dahinter. Ich möchte nur kurz auf drei wesentliche Aspekte eingehen.

Veränderung

Jede Verbesserung ist per se eine Veränderung. Es muss für eine Verbesserung der Lage also etwas modifiziert werden. Im Sinne der Methodik wäre dies eine Aufforderung zur aktiven Gestaltung der Methode selbst. Wenn wir nicht unser "wie" ändern, dann kann es auch kein besseres "was" geben.

Veränderung bedingt an sich auch schon einen operativen Ausgangszustand. Es muss demnach ein wertgebenden, zweckgebundenen und anwendungsfähigen Zustand geben, bevor es zu einer Veränderung kommen kann. In einfacheren Worten: Das Ziel muss schon erreicht sein, um es daraufhin verbessern zu können. Im Sinne der Software-Entwicklungs-Methodik lässt dies sich gut mit der iterativen Lösungskonzeption vereinbaren.

Damit einher geht natürlich auch die Wahrnehmungsfähigkeit der Handlung selbst. Veränderung muss wahrnehmbar sein, sonst wäre es als Veränderung nicht erkennbar. Diese Aussage fordert uns also indirekt dazu auf, den vor uns liegenden Handlungsrahmen messbar zu gestalten.

Bewertung

Der zweite wichtige Aspekt einer Verbesserung ist die Bewertung. Die Bewertung ist die eigentliche Brücke von der Veränderung hin zur Verbesserung. Wenn wir also verbessern möchten, müssen wir auch bewerten möchten - und können.

Ein besonders interessanter Aspekt der positven Bewertung ist die sog. Bewertungsgrundlage. Sie ist quasi der operative Kontext, in dem die Bewertung stattfindet. Ich möchte nicht zu tief in dieses Gebiet eindringen, will aber dennoch erwähnen, dass es zwei wesentliche Perspektiven der Bewertungsgrundlage gibt.

Die zwei "Verdächtigen" sind natürlich unsere zwei großen Bewußtseinsaspekte, nämlich die sog. Ratio und Emotio. Während die Ratio eine nüchterne, logische Faktengrundlage schafft, ist die Emotio für das ebenso berüchtigte wie ominöse "Bauchgefühl" zuständig.

Subjektivität

Der letzte wichtige Aspekt der Verbesserung auf den ich in diesem Artikel eingehen möchte ist die Subjektivität. Sie ist - etwas flapsig ausgedrückt - eine kostenlose Beigabe der Bewertung. Denn: jede Bewertung ist subjektiv. Es ist schlußfolgernd auch die Verbesserung subjektiv.

Subjektivität ist für die Verbesserung ein ganz wesentliches, wenn nicht sogar entscheidendes Merkmal. Insbesondere für eine gemeinschaftliche Verbesserung, wie sie oft bei agilen Methoden propagiert und gelebt wird, ist die Beachtung der Subjektivität geradezu ein Erfolgsfaktor.

Besser?

Obwohl ich durchaus noch viele Einzelheiten zu dem Wesen der Verbesserung und ihren tragenden Säulen erläutern könnte, möchte ich mich an dieser Stelle nicht zu intensiv damit befassen. Mir geht es primär darum, die Sensibilität zur Verbesserung im Kontext der Software-Entwicklung zu schärfen. Nicht nur aus der Team-Perspektive, sondern auch für die technische und fachliche Ebene.

Es ist für mein Defürhalten wichtig, sich der Verbesserung fokussiert zu widmen. Zumeist wird der Fokus auf die Handlung selbst gelegt, welche man als - vermeintliche - Verbesserung umzusetzen versucht. Jedoch sind die vor- und nachrangigen Aktivitäten zur Verbesserung auch einer gezielten Fokussierung würdig. Besonders Überlegungen a priori sind oftmals effektiver als man es vermuten mag.

Darüber hinaus möchte ich diese kurze Abhandlung mit ein paar Anmerkungen schließen. Wer nun glaubt, mit der Betrachtung von Veränderung, Bewertung und Subjektivität ließe sich Verbesserung gezielt erkennen und umsetzen, den muss ich leider enttäuschen.

Es ergeben sich noch eine Reihe weiterer Faktoren und Rückschlüsse, die es zu beachten bedarf. Es gibt sogar eine direkte Konsequenz aus der hier vereinfacht dargestellten Betrachtung von Verbesserung. Doch statt sie zu nennen, möchte ich den Interessierten dazu ermutigen, sich selbst gedanklich auf die Suche nach dieser wichtigen Erkenntnis zu machen.

Never change a running system.

Now, this is clearly nonsense. Despite the fact, that most native speakers would rather prefer to say "if it ain't broke, don't fix it", the message of above statement is simply wrong.

In Germany, this phrase is often used in response to a change or improvement that failed, or otherwise caused trouble. Often, the person saying it wants to express that the change being made did not improve the overall situation, but caused trouble or even damage.

However, it's noteworthy that in most cases this person would've wanted to express a different perspective than what is being stated by this pseudo-phrase. Although many people say "Never change a running system", they most often wanted to say:

Never break a utilized system.

More precisely, "avoid regression of a utilized system in operation". Now, this in fact is quite a different meaning and perspective from the phrase most people are used to say, even when they initially wanted to express that a negative change on an operational system should not happen.

Even more, the described intent actually implies that changing a system is encouraged. Thoughtful, innovative or demanded changes should be applied to the system in order to i.e. keep its utilization rate, improve the functionality, or align to environmental changes. In addition, those changes need not only to be thoughtfully crafted, but actually being specified and tested in a professional manner. Hence, the intent even prompts for agile specification and testing practices.

That's why you - especially my german readers - should get used to say:

Keep the system going.

Nun, zu Beginn meines Interesses an Organisations- und Gruppengestaltung - so ca. Ende 2006 - hatte ich noch einen ganz anderen Zugang zu dem Thema als Heute. Das ist insofern interessant, als das seither die Theorie dazu mein stetiger Begleiter ist. Damals dachte ich nicht, dass ich jemals in die Gelegenheit kommen würde, dieses Wissen eigenständig anzuwenden. Heute, knapp 7 Jahre später, mache ich oft von diesem Wissensrepertoire gebrauch.

Netzwerk, Autonomie, Emergenz

Während dieser Zeit haben mich drei Themenblöcke immer wieder eingefangen. Da wäre zunächst einmal das Netzwerk als Organisationsform. Es gibt viele Ausprägungen von Netzen, angefangen von Stern- und Ringnetzen, bis hin zu All-Channel-Netzen und der geliebten Graphentheorie.

Dem schließt sich nahtlos das Thema der Autonomie an. Autonomie ist ein faszinierendes, jedoch umso schwerer greifbares Themengebiet. Ich musste gerade bei der Autonomie viel lernen und verstehen, bevor es sich in das Gesamtbild in der Organisationsentwicklung einbetten ließ.

Die Krönung ist allerdings das Phänomen der Emergenz. Obwohl ich mich gerade mit der Emergenz als erstes von diesen drei Themen auseinandergesetzt habe, ist die Emergenz für mich immer noch nicht vollends überschaubar. Zwar habe ich mittlerweile einiges an Wissen und Erfahrung angesammelt. Doch gerade hier liegt die Schwierigkeit verborgen: Mit dem zusätzlichen Wissen kommen oft noch mehr Fragen auf.

Wie dem auch sei. Der Zufall will es nun, dass ich einen Vortrag darüber nun drei Mal in nahezu exaktem 3-Jahres-Rhytmus gehalten habe. Unlängst bei der bekannten OOP 2013 als Pecha Kucha in München. Drei Jahre davor als Kurzvortrag bei der O'Reilly Ignite, wieder in München. Die Premiere des Vortrages war ganz ohne Bilder - nur als Motivationsrede - 2007 bei dem "Tag der Ideen", einer Fachtagung für alternative Ideen, wieder in München.

Grund genug, dass ich die Folien zu dem "Vortrag" nun auch Online zur Verfügung stelle. Doch damit nicht genug, denn es gibt noch eine weitere Besonderheit: Sowohl der Pecha Kucha bei der OOP, als auch der O'Reilly Ignite-Talk wurden per Video aufgezeichnet:

• Video des Pecha Kucha bei der OOP 2013
• Video des Ignite Talks bei der Ignite MUC 2010

In diesem Sinne: Netzwerk - Autonomie - Emergenz.
Das braucht das Unternehmen von Heute.*

*seit über 6 Jahren sage ich das. :-)

Es ist zwar schon eine Weile her, als ich über meine Sicht der 5 Schwachpunkte von Scrum erzählt habe. Einer dieser Schwachpunkte ist eben die Planung und das Design der Stories in einem Sprint.

Planen und Designen: Jetzt!

In Scrum ist die Planung und das Design der User Stories genau deshalb ein Schwachpunkt, weil es formal - als Bestandteil des Frameworks - nur im Sprint-Planning-Meeting manifestiert ist. Sogar eingespielte Scrum-Teams schaffen es kaum, in 4 bis 8 Stunden alle User Stories eines Sprints mit einer gangbaren Lösungskonzeption zu bereichern. Das Problem ist offensichtlich: die unnötige Fokussierung auf das Sprint-Planning-Meeting.

Jetzt gibt es sicherlich Scrum-Freunde, die einem solchen Argument mit “Scrum verbietet ja nicht, dass man mehr als nur eine Sprint-Planung macht”. So einen Satz muss man erst einmal sacken lassen. Fadenscheinig, Lachhaft, Unpräzise. Das sind die Eigenschaften eines solchen Arguments.

Darüber hinaus beschweren sich Entwickler und Architekten mit ausgeprägtem Sinn für Software-Design über mangelnde konzeptionelle Integrität, wenn man “agil lossprintet”. Sie empfinden die Sprint-Plannings als “aktionistisch” und “affektiert”. Manche sagen sogar, dass Sprint-Planning sei ein Paradebeispiel für das berüchtigte Design by Comittee.

Doch nun genug der Kritik. Wie auch in meinen Verbesserungsvorschlägen zu der besseren Sprintdauer als auch zum besseren Scrum Master möchte ich in diesem Artikel ein paar Anregungen zu einer besseren Planung und einem besseren Software Design geben.

Zeitlose Kunst

Aus meiner Sicht gibt es eine besonders wichtige Erkenntis, wenn es um agiles Software-Design im Allgemeinen geht: Software-Design ist zeitlos. Zeitlos im Sinne des Zeitpunktes und nicht unbedingt im Sinne der Dauer. Die gemeinschaftliche geistige Leistung des Designs von Softwarelösungen ist rein konzeptionell in der Agilität nicht mit einem festen Zeitpunkt vereinbar.

Das heißt: Die Sprint-Planung als Meeting (sowohl der erste, als auch der zweite Teil) sind in ihrem Schwerpunkt organisatorisch. Das Sprint-Planning sollte nicht als “Planungs-und-Design-Workshop” wahrgenommen werden, sondern als eine “Ermittlung des Status-Quo”.

Das Ziel des Sprint-Plannings ist es eben nicht, konzeptionelle Produktivität abzurufen. Die “Wie machen wir das?”-Frage im zweiten Sprint-Planning zielt nicht darauf ab, Problemstellungen zu Software-Design mit Lösungskonzepten aufzulösen. Die Frage regt vielmehr dazu an, das gesamte verfügbare Arsenal an Wissen und Informationen bzgl. der Herangehensweise zu einer User Story abzurufen. Das ist ein kleiner, aber entscheidender Unterschied.

Besonders unerfahrene (oder unwissende) Scrum Master machen oft den Fehler, in den Sprint-Plannings das Team mit wiederholten “Wie können wir das lösen?”-Fragen auf eine schnelle und unüberlegte Konzeption zu drängen. Natürlich ist es gut, nochmals sich selbst zu fragen, ob alle Fakten auf dem Tisch sind. Aber das war’s dann auch. Wenn Ungewißheiten oder Fragen offen bleiben, dann ist das eben so.

Storyboards

Hat man es als Team mal gedanklich geschafft, die Aktivität des Software-Designs und damit auch der kurzfristigen Planung von einer zeitlichen Schranke zu entkoppeln, werden viele Dinge offensichtlicher und leichter.

So stellt man dann auf einmal fest, wie irreführend eigentlich die Bezeichnung “Estimation Meeting” für die Veranstaltungen sind, in denen unter Anderem erstmals über Stories gepokert wird. Eigentlich sollten die Meetings eher “Story Gathering” genannt werden. Denn neben der eigentlichen Erhebung von “Story Points” geht es gerade dabei um den Austausch von unterschiedlichen Problem- und Lösungsmodellen zu einer User Story.

Mehr noch, man stellt weiter fest, dass es völlig normal und legitim ist, während den Daily Scrums weitere Tasks auf das Board zu schreiben. Oft sind es gerade die teaminternen Gespräche über die neuen Tasks nach dem Daily, die konzeptionell wertvoll sind.

Mit der Zeit werden Teams, die die Konzeption von Software-Komponenten als stetigen Begleiter der Entwicklung selbst verinnerlicht haben, verschiedene weitere Maßnahmen eigenständig herausarbeiten. So ist es überaus hilfreich, wenn sich Teams sog. “Storyboards” zulegen.

In XP sind das meistens physische Boards oder Wände, an denen ein konzeptioneller und technischer Überblick über die User Story gegeben wird. Storyboards werden nicht erst im Sprint aufgestellt, sondern werden meist 1-2 Sprints im voraus schon im Flur oder am Graffiti gesichtet.

Die Reise des Konzeptes

Eine weitere Maßnahme zur Verbesserung der “suboptimalen” Design- und Planungsgrundlagen von Scrum ist wiederum eine aus XP entlehnte Methode der gemeinsamen Erarbeitung von Lösungen. Gemeint ist hier das altbewährte “Task Travelling”-Prinzip. Es war eines der ersten XP-Planungstechniken, die ich lernen durfte und hat sich bis heute als ein sehr wirksames Mittel erwiesen.

Im Kontext des Software-Designs und der User-Story-Planung werden dabei eine oder wenige User Stories - z.B. diejenigen, die in dem Estimation Meeting vorgestellt wurden - als Paket im Team “herumgereicht”. Jeden Tag bewegt sich das Paket von Team-Mitglied zu Team-Mitglied, bis es schlußendlich wieder beim ersten Mitglied landet.

Hat der Einzelne nun einmal so ein “Paket”, sollte schon im Daily erwähnt werden, dass man sich mit dem Paket beschäftigen wird. Das Paket wird in einer kurzen Session vom Vorgänger übergeben. Meist mit Informationen über den aktuellen Stand und die Herausforderungen, die zu erwarten sind. Danach entwickelt man in ein oder mehreren Stunden alleine die Konzepte weiter. Die Erkenntnisse bzw. Ergebnisse werden im Paket festgehalten und mitgegeben. Am Folgetag wird das Paket - unabhängig von den Ergebnissen - weitergereicht.

Das Resultat dieser “Reise des Konzeptes” ist oft verblüffend gut. Alle Beteiligten kennen die User Story und mögliche Lösungspfade, es liegt im Allgemeinen ein dokumentiertes Konzeptpapier vor und alle Teammitglieder konnten gemeinsam am Konzept wirken. Ich habe sehr positive Erfahrungen mit Task Travelling und der “Reise des Konzeptes” gehabt.

TDD und BDD

Zu guter Letzt sollte man TDD, BDD und ATDD als agile Designverfahren unbedingt in Betracht ziehen. Ich persönlich lehne mich da auch gerne weit aus dem Fenster. Ein Team, welches kein TDD, BDD oder ähnliche Verfahren einsetzt ist in meinen Augen einem Team mit TDD / BDD haushoch unterlegen. Agiles Design ist ohne TDD und BDD de Facto sehr schwer durchführbar.

Interessanterweise fängt gerade BDD auch schon beim Storyboard und den Akzeptanzkriterien an. Erfahrene Team-Mitglieder schreiben z.B. schon während des Sprint-Plannings ihre Specs zusammen und checken sie auch sofort ein.

Darüber hinaus werden in der aus dem TDD bekannten Keyword-Analyse sofort Kandidaten für Klassen und Methoden herausgearbeitet. Obwohl ich das selbst leider nie gemacht habe, empfand ich es schon smart und hilfreich, als ein sehr erfahrener Entwickler während des Meetings ab und zu in seine Konsole kurze Klassendefinitionen eintippte:

echo “class Recommendation:
  pass” > recommendation.py

Es ist sicherlich auch eine Frage des Geschmacks, wie man die Konzeption schlußendlich festhält. Hervorzuheben ist allerdings, dass es besonders hilfreich ist, früh in die Codebasis einzutauchen und sog. “executable specs” zu formulieren.

Kontinuierliche Konzepte

Summa summarum lässt sich folgendes schließen: Scrum hat den Schwachpunkt, dass es wenig greifbare Mittel für ein agiles Software-Design - und damit auch eine agile Iterationsplanung vorgibt. Dieser Umstand macht es notwendig, verschiedene Design- und Planungsmethoden in den Alltag agiler Teams einzubeziehen. Ganz besonders Praktiken aus XP können bei agiler Software-Entwicklung einen großen Mehrwert liefern.

Schlüssel für eine bessere Planung und ein besseres Design ist die gemeinschaftliche Erkenntnis, dass sowohl agile Planung als auch agiles Software-Design eine kontinuierliche Aufgabe ist, die stetig als kollaborative Teamaufgabe umgesetzt werden will.

The good thing about this fact is: It does not tell you anything about the “completeness” of my experience. This is good for me as well, since it does mean that I’m not a “complete” agile practitioner. Nobody is. And that’s why I like to be an agile practitioner. Learning and improving for the better. Day by day.

And this actually is exactly the reason why I was so excited lately to be able to learn things about XP being new to me. Although I consider my knowledge and experience pretty well within this agile methodology, I’m still learning very useful new things.

One of those very useful things I learned a few months ago is the Pair Stairs chart. This chart typically is placed somewhere on the team or sprint board. It’s purpose and effectiveness is very simple: help the team do pair programming.

The chart itself is no more than a simple matrix of all team members (including testers, business analysts, sysops). Whenever two team members pair up, they mark their “pairing” with a dot, check or simple line. The team always strives to get the complete chart filled, which effectively means that the team has undergone all pairing combinations.

This chart often is called “pair stairs” because it looks like a “stairway” to knowledge sharing and team performance. If all stairs have been advanced at the end of the sprint, the team (and completely filled out chart as well) is called “pairmuted” (I think the reference to the mathematical concept of permutation is obvious here). Hence, a “pairmutating team” is a team where all team members paired with each other at least once within a sprint.

A very smart and useful extension to the “pair stairs” chart are task markers. Instead of marking the pair with a single checkbox on the stair, the topic or task is being placed on the stair using a post-it. It turns out that this variation is very powerful, since it enables everyone on the team to see how the topics are being tackled by the team.

Although I learned about this chart just a few months ago, the chart itself is quite known and established as an XP practice. It’s been in use for over a decade now in XP community and has proven to be very effective.

I personally remember that a few participants at QCON 2009 mentioned to work with “pair stairs” in their teams. I honestly have to admit that by that time I didn’t knew what they were takling about and that I haven’t felt any urge to ask them what these “stairs” are all about.

Now, four years later, I know better.

Notizen eines Nerds

• Culture Change Vector
• CI Secrets - Die Notizen
• Amigo Agilo - Die Bedeutung
• Das Wesen von Verhandlungen
• Agile Verhandlung
• Der Berater
• Lines Of Code Kata - Notizen
• David Parnas über die Dokumentation
• Die erste Story des Product Owners
• Agiles RE für RE
• The Feature Circle
• Das 'One Piece Flow'-Modell

More Nerd Notes

Der aufmerksame Leser meines Blogs kennt sicherlich auch die letzten beiden Ausgaben meiner Nerd-Notizen, nämlich die Notizen eines Nerds 2011 als auch die Notizen eines Nerds 2010.

Ich wünsche uns allen gemeinsam ein gesundes, frohes, glückliches und erfolgreiches Jahr 2013!

Ein sehr gutes und auch oft von ihm selbst zitiertes Beispiel ist der Begriff der "Agilität". Durch den Erfolg und den Zuspruch der agilen Bewegung bekommt dieser natürlicher Weise auch mehr Interesse (von außen) als auch eine größere Basis als Anhängerschaft. Das führt zur Interpretation und Anwendung der agilen Werte in verschiedensten Kulturen und Kontexten, welches wiederum sich auf den interpretationsbedürftigen Begriff "Agilität" reflektiert.

Der Begriff und dessen Semantik verbreitert sich also automatisch mit der steigenden Popularität eben der Konzepte, welches durch diesen Begriff repräsentiert wird. Ich persönlich finde diese Argumentation schlüssig und konnte sie selbst auch für verschiedene Begriffe wiedererkennen.

Regression > Diffusion

Aber es geht meiner Meinung nach bei manchen Begriffen noch einen Stück weiter. Gerade für den Begriff der "Agilität" lässt sich in manchen Situationen meiner Meinung nach eine weitere Stufe feststellen. Dabei wird der Begriff nicht nur "gedehnt", wie es Fowler so schön herrschaftssprachlich umschreibt, sondern auch noch von seiner originären Bedeutung distanziert.

Um mich nun an das für meinen Geschmack subtil prahlerische Vokabular von Fowler anzufügen, möchte ich diesen eben beschriebenen Bedeutungsverlust als semantische Regression bezeichnen.

(Anmerkung: Ich werde im Übrigen über den gesamten Beitrag hinweg diesen Unterton der fingierten "Herrschaftlichkeit" mit meiner Wortwahl weiter versuchen aufrecht zu erhalten, um so auf dessen Wirkweise und Wirksamkeit aufmerksam zu machen.)

Die semantische Regression ist also ein Prozess, bei der die Bedeutung des ursprünglichen Begriffs schrittweise von seiner selbst abgetragen wird. Dabei entsteht nebenläufig auch ein Rekonstruktionsprozess, der getarnt als Interpretationskraft die Begrifflichkeit in eine neue Deutungsrichtung zu schieben versucht. Bei erfolgreicher semantischer Regression ist das Resultat also ein Begriff, der schlußendlich mit der originären Bedeutung kaum bis gar nichts gemein hat.

Nun mag man annehmen, das ein Bedeutungswandel - ähnlich wie der Diffusion - einen negativen Character hat. Das ist zu weiten Teilen auch der Fall. Dennoch kann es durchaus auch vorkommen, dass ein ursprünglich "schwieriger Begriff" degeneriert um sich daraufhin wieder zu einem "akzeptableren Begriff" zu regenerieren. Ich werde nochmals auf die Bewertung des Bedeutungswandels zurückkommen. Für den Moment ist es ausreichend zu erkennen, dass der Prozess des Wandels zum Schlechten hier als Regression bezeichnet wird.

Nähert man sich nun den Begriffen der Diffusion und Regression im Kontekt der Semantik, so ist eine Abgrenzung der Begrifflichkeiten unerlässlich. In ihrer eigenständigen Darstellung kann man feststellen, dass eine Diffusion einer Bedeutung auf eine Erweiterung (im verständnisreduzierten Sinne) hinweisen möchte, während die Regression einer Bedeutung eher als eine Verschlechterung (ebenfalls im verständnisreduzierten Sinn) zu verstehen ist.

In unserem konkreten Arbeitsumfeld der Software-Entwicklung lassen sich interessante Beispiele finden, die man in beide Kategorien einzuordnen versuchen kann. Eine Einordnung ist natürlich der Subjektivität des Ordnenden unterlegen. Dennoch möchte ich ein paar Beispiele als Anregung zum Nachdenken geben.

Beispiele für mögliche semantische Diffusion:

• Tool
• Schätzung
• Unit Test
• Refactoring

Beisiele für mögliche semantische Regression:

• Framework
• Planung
• Agil
• Requirement

Für die relativ naive Definition und Betrachtung der semantischen Regression sind diese Beispiele sicherlich genügend Anreiz zum Differenzieren.

Regression der Agilität?

Ich möchte doch nun wieder zum Ausgangspunkt zurückkehren und wieder die "Agilität" als Begriff in den Fokus der Betrachtung stellen. Ich behaupte, dass sich nach den nun mehr als dutzend Jahren der "agilen Bewegung" der Begriff der Agilität hinsichtlich seiner ursprünglichen Bedeutung verschlechtert hat. Ich werde hier nicht das naheliegende tun, welches natürlich die Analyse der ursprünglichen als auch der jetzigen Bedeutung der "Agilität" wäre.

Was ich statt dessen tun möchte ist auf ein paar "Hinweise" deuten, die bei solch einer Betrachtung hilfreich sein können. So kann man zum Beispiel feststellen, dass sich das Agile Manifest seit dessen Formulierung nicht geändert hat. Weiterhin ist offensichtlich, dass Scrum der bekannteste und am meisten eingesetzte Vertreter eines agilen Verfahrens ist. In letzter Zeit hat sich auch in der agilen Community das Kanban-Verfahren stärker präsentiert. Die Zahl der "agilen Werkzeuge" - angefangen von angeblich super-produktiven digitalen Boards bis hin zu kompletten Produkt-Portfolio-Management-Systemen - ist in den letzten Jahren förmlich explodiert. Etablierte Konsortien und sog. Fachexperten interessieren sich seit Längerem auch für eine Formalisierung bzw. Standardisierung von Agilität.

Mit all diesen Hinweisen lassen sich sicherlich weitere Gedanken entwickeln, die zu einer Beurteilung führen können, ob nun die Agilität als Begriff einer semantischen Diffusion unterliegt, oder ob - wie von mir in dem Raum gestellt - auch eine semantische Regression möglich ist bzw. stattfindet.

Ich persönlich denke, das gerade der Begriff der "Agilität" oft breit und platt verwendet - ja sogar "entwendet" wird. Es gibt mittlerweile nicht nur agile Tools oder agile Standards, sondern auch "agile Workflows" (klingelt's?) bzw. "agile Frameworks" (läutet's?). Es ist quasi schon ein Zeichen der Etikette in der Software-Entwicklungs-Branche, allen wichtigen und neuartigen Produkten oder Verfahren das Verb agile voranzustellen, um sich sogleich als fortschrittlich, offengeistig und flexibel darzustellen.

Diffuse Interpretationsräume

An dieser Stelle denke ich habe ich genug Denkanstöße für eine eigene Meinungsbildung gegeben und möchte mich von der Ebene der Hypothese wieder zurück auf den der Empirie begeben. Unzweifelhaft ist demnach nicht nur die Stichhaltigkeit der Feststellung der semantischen Diffusion von Fowler vor über 6 Jahren. Vielmehr ist auch kaum anzuzweifeln, dass die breite Anwendung verschiedener agiler Verfahren (wie z.B. Pair Programming) kombiniert mit dem durchaus erwünschten äußeren Einfluss neuer Erkenntnisse und Verfahren (wie z.B. Kanban) einen großen Interpretationsraum abbilden.

Entscheidend ist es hier meiner Auffassung nach, dass sich Impulsgeber, Trendsetter und Vordenker - wie eben auch ein Martin Fowler - sich klar zu Veränderungen äußern und die allgemeine Meinungsbildung vorantreiben. Es wäre meines Erachtens nicht förderlich, sich der sachlichen Auseinandersetzung mit Alternativen oder Neuerungen zu entziehen oder sie sogar abzulehnen. Neuerungen müssen in diesem Fall nicht nur dinglicher Natur sein, sondern können eben auch verschiedene andere Aspekte einschließen, wie z.B. "Agile Enterprise" oder "Agile Design".

Wie auch Fowler komme ich dabei zum vorläufigen Schluß, dass es nichts hilft zu lamentieren. Es ist vielmehr wichtig zu erkennen, dass ernsthafte und skeptische Auseinandersetzung mit dem Fortschritt ein aufwendiger, manchmal kräftezehrender Prozess ist. Der jedoch ist nicht nur notwendig, sondern eben auch einflussnehmend auf den Fortschritt selbst.

Die ständige Beschäftigung und Rekapitulation des Verständnisses von Agilität sind es, die uns allen dabei helfen, sowohl die semantische Diffusion als auch eine mögliche Regression zu verhindern - oder zumindest zu mildern. Ich kann es deswegen kaum verstehen, warum ich manchmal intelligente, progressive Entwickler treffe, die das Wort "agile" eher meiden, als es aus ihrer Perspektive klar darzulegen.

Ja, es kommt sogar vor, das vereinzelt ein Raunen und Seufzen zu hören ist, wenn man "schon wieder" über "agile Werte" oder "agile Entwicklung" redet. An genau diese Meinungsfraktion wende ich mich zu und entgegne sehr gerne: Fällt euch eigentlich nicht auf, dass gerade die stetige Iteration und Verbesserung Merkmale eures eigenen Wirkens und Erfolges sind?

Raus mit der Sprache

Der Verbreiterung oder Verschlechterung einer Bedeutung kann man entgegentreten, in dem man eine gemeinschaftliche Sicht auf den Begriff und dessen Bedeutung entwickelt und aufrecht erhält. Dazu gehört nicht nur das Schärfen der Begrifflichkeit an sich, sondern eben auch die aktive Gestaltung der Entwicklung des Begriffes. Konsequenter Weise ist die Teilnahme an der Diskussion und die Äußerung der eigenen Wahrnehmung über den Begriff sowohl für das eigene als auch für das allgemeine Verständnis förderlich.

Damit möchte ich auch schon meine Vermutung zur semantischen Regression abschließen und zu guter Letzt noch den Blick hin zur Sprachwissenschaft werfen. Für die ist nämlich der Prozess des Bedeutungswandels ein durchaus natürlicher Prozess, der zugleich auch ein Zeugnis der Anwendung und Anwendbarkeit des Begriffes ist. Auch dort gibt es eine Art Diffusion und Regression der Semantik, welche dort aber Amplifikation (Bedeutungserweiterung) bzw. Pejoration (Bedeutungsverschlechterung) bezeichnet werden.

Letzteres - die Verschlechterung einer Bedeutung - ist ein durchaus streitbarer Begriff. Besonders, wenn man sich die Frage stellt, welche Kriterien denn nun für eine Beurteilung der Verbesserung oder Verschlechterung einer Begrifflichkeit und dessen Verständnisses herangezogen werden sollen. Es wandert bei der Kategorisierung in "Besser" und "Schlechter" immer der Schatten der Subjektivität mit dem Wesen der Beurteilung mit.

Nichtsdestotrotz gibt es Möglichkeiten sich einer solchen Beurteilung relativ objektiv zu nähern. So kann man z.B. die Bewertung der semantischen Schärfe auf den Wirkungsgrad der Verständlichkeit reduzieren. Konkret gesprochen: wenn man längere Zeit braucht, um die Bedeutung hinter einem Wort zu verstehen, so könnte man die Bindung des Begriffes zu dessen Bedeutung verglichen zum schnell Verständlichen als "schlechter" bezeichnen.

Das auch diese Ansätze nicht frei von jeglicher Individualität sind, ist wohl offensichtlich. Aber: es liefert mögliche Dimensionen, um sich hin zu einer allgemein tragfähigen Beurteilung zur semantischen Schärfe bzw. Unschärfe zu nähern.

Mit Kommunikation zur Konvention

Die Erkenntnis, die sich mir durch die Betrachtung der Beziehung zwischen Begriff und Bedeutung aus Sicht der Verständlichkeit erschließt, ist relativ einfach zu formulieren. Es Bedarf einer stetigen Kommunikation mit und über den Begriff und dessen Bedeutung, um zum Wohle des allgemeinen Verständnisses sowohl den Begriff als auch die Bedeutung zu konventionalisieren.

In diesem Sinne kann ich nur jeden ermutigen, sich mit anderen über Agilität auszutauschen, darüber zu reden und zu schreiben. Die konstruktive Grundhaltung vorausgesetzt, kann solch ein Austausch nur von Vorteil für den Einzelnen wie auch für die Gemeinschaft sein. Ein Ausweichen oder Ignorieren alleine nur vom Begriff selbst ist schon eine Art der Kapitulation gegenüber des eigenen Klärungsbedürfnisses über die Bedeutung des Begriffes.

Es bleibt also festzuhalten:

Die Bedeutung eines Wortes ist das, was die Erklärung der Bedeutung erklärt.*

*(Ludwig Wittgenstein)

A few weeks ago I read a very interesting article by Stefan Roock about the correlation between Definition of Done and Definition of Ready. For those who don't know any of those terms, I'll just summarize it briefly. The "Definition of Done" (DoD) is a team agreement about the quality criteria a given task should meet before it actually can be considered done. Likewise, the "Definition of Ready" (DoR) is a set of quality criteria a user story should fulfill in order to be "ready" for the development team.

Now the interesting part of abovementioned article actually is the correlation he is drawing between both of them. His argument seems reasonable: While the "Definition of Done" should grow over time, the "Definition of Ready" should shrink over the same time.

Figure 1: A wrong assumption on how DoD and DoR should develop over time.

And that's what made me scratch my head. To be honest, I not only was wondering why this should be as laid out in the article, but was equally wondering about the weak reasoning behind that statement. My perspective is the absolute contrary: I firmly believe that both DoD and DoR should grow and be extended over time. That's why I was very irritated when I read this - well, to my perception sort of naive statement.

So, let's just get into it: Why should both DoR and DoD tend towards growth? The reason behind this is quite easy. Both DoR and DoD share the same purpose and characteristics. They are a transparent means to agree upon the quality criteria for a certain deliverable (or type of deliverable). One might generalize this shared purpose to the term "Definition of Delivery". (And voila, here's this articles title).

For me, there are two very important aspects of such a "Definition of Delivery", which I'll abbreviate as "DeDe" further on. First of all, a DeDe targets a transparent definition of quality characteristics for the deliverable in question. It's important to realize that it's not adding up to the core value of the deliverable itself, but rather view the deliverable from the supportive and qualitative perspective.

Second, there's an even more important thing to know about a DeDe. A DeDe is self-directed. This basically means that any "Definition of X" is defined and directed towards its author. This property of self-directedness is a key property. It means that only the producer(s) of the deliverable are eligible to define the DeDe for themselves.

Figure 2: A desirable growth of self-expected quality through DoD and DoR over time.

And this is mainly why I disagree with Stefan's statement. The very same as DoD is defined by the team, the DoR is defined by the Product Owner. All just with the purpose to deliver better results. Hence, both DoR and DoD should be improved over time (mainly by extension). No third party should be able to alter or define the DeDe. However, that's actually my impression of what happens in Stefan's article.

I recognize that Stefan looks at the DoR from the team perspective. From this perspective he concludes that the DoR should be kept reasonably small in order to enable the team to work on the user story as early as possible. And as time goes by, the team does know more and more about the product itself. The DoR can be lowered even more now, since the team has gained a solid knowledge of the domain in order to reasonably handle even the bare minimum user story written on a post-it.

As fair as this might sound in first place, it's a critical thing to look at in the long run. The ultimate "sense for quality work" might get lost on PO side. User stories might then not have essential acceptance criteria to ensure the proper realization of the business value. Even more, the "what" part of the development might be influenced too much by the team itself. That's surely something not desirable.

Instead, I think it's important to let the PO decide how the qualitative characteristics of a user story should look like. If he thinks that it's an important quality improvement that every user story should have personas and two business case studies, then he should be able to independently define that in the DoR.

Of course, there's this risk of "over-engineering" a user story. We all are afraid of such a scenario: what if the PO starts to write extensive 200 page documentation about every user story because he thinks that it's needed for a "high quality user story"? Well, that's why Scrum has Scrum Masters to ensure a well-balanced and reasonable usage of all practices and tools. Oh, and by the way, the risk of over-engineering is surely not only limited to the DoR. It might just equally well happen at the team level with a DoD.

To put it simple and straight, my point is that a "Definition of Delivery" of any kind should be a self-directed agreement about the quality criteria of a deliverable. As such, it strives to be improved and extended until a point is reached where the efforts for the properties of quality outweigh the benefits of them. This decision is normally being made by the consumer of the deliverable in question (i.e. the team if we were talking about a DoR on user stories).

In consequence, I strongly favour the will to extend and improve both the Definition of Done and the Definition of Ready. This is very much the opposite of the 'raise DoD, lower DoR' statement of Stefan. I personally think that such a one-dimensional view of DoD and DoR might cause very negative effects in practice. Hence, I'd like you to be very thoughtful and attentive when it comes to dealing with either Definition of Ready or Definition of Done.

Obgleich ich erst zu den Nachmittags-Veranstaltungen hinzugestossen bin, habe ich dennoch 3 sehr inspirierende Vorträge gehört. Zwischendurch hatte ich auch das Vergnügen meine Präsentation über "Agiles Software-Design" vortragen zu dürfen. Doch nun erst einmal alles der Reihe nach.

Gestaltung von Vorgehen

Die erste Session die ich besuchte war der Vortrag "Scrum vs. Kanban" von Thomas Schissler. Im Großen und Ganzen empfand ich den Vortrag als einen guten Rundflug über das angeschriebene Themenfeld, wobei ich deutlich eine schwerere Gewichtung zu Kanban wahrgenommen habe.

Die Ausführungen von Thomas zu Kanban waren im Rahmen der Kürze der Vortragszeit angemessen und sachlich. Ich empfand auch die unparteiische Herangehensweise zu beiden methodischen Feldern als positiv. Thomas wurde überdies nicht müde zu betonen, dass eine Gegenüberstellung von Scrum und Kanban keine "Entscheidungssituation" hervorrufen sollte, sondern vielmehr die "wenigen Gemeinsamkeiten und deutlichen Unterschiede" hervorheben soll. Eine wie ich finde gelungene Einführung, ohne zu sehr in belastende Details zu flüchten.

Gestaltung von Spezifikation

Der zweite Beitrag den ich bestaunen durfte war der Vortag "Testing war gestern, Spezifikation ist heute." von Björn Rochel und Alexander Groß. Der Vortrag thematisierte den geistigen und methodischen Übergang von validierungsorientiertem Testen hin zur gestaltungsorientierten Spezifikation. Da sowohl Björn als auch Alexander in dem Themenfeld ausgewiesene Experten sind, waren meine Erwartungen entsprechend hoch.

Um es kurz zu fassen - meine Erwartungen haben sich bestätigt. In einer Stunde wurde mir eine gleichsam informative und anspruchsvolle Abhandlung dargelegt, die sich zunächst mit grundlegenden Themen wie Motivation und Kontext zur "programmatischen Spezifikationsgestaltung" befasste und darauf aufbauend einen guten Überblick zu Werkzeugen und praktischem Einsatz lieferte.

Gestaltung vom Modellen

Eine ganz besondere Freude war es für mich, dass ich bei dem "Functional Design Dojo" von Sergey Shishkin teilnehmen durfte. In diesem "Design Dojo" hob er die Metapher des aus den Coding Dojos bekannten Übungsraumes aus dem praktischen Kontext der konkreten Gestaltung heraus, um sie sogleich in den praktischen Kontext des abstrakten Gestaltens wieder einzubetten.

Das Design Dojo hatte eine sog. "Architecture Kata" zum Thema, welche wir in kleinen Gruppen (à 3 Teilnehmer) auf einem A2 Blatt mit den Hilfsmitteln von Stift und Papier lösen sollten. Lösungsziel war das Skizzieren eines Zielsystems, welches insbesondere den Ansprüchen der Änderbarkeit und Erweiterbarkeit genügen sollte.

Die Erfahrung des Dojos als auch der Interaktion mit den Teilnehmern möchte ich nicht mehr missen. Das Format, die Gestaltung des Dojos, die Kata als auch unsere Bemühungen hin zu einem Zielsystem waren für mich sehr lehrreich.

Es tut gut zu wissen, dass stetige Übung als ein wichtiges Mittel des Lernens und Verbesserns von Fähigkeiten von vielen professionellen Entwicklern angenommen wird. Sergey hat mit diesem Dojo unzweifelhaft einen weiteren wichtigen Beitrag dazu geleistet.

Gestaltung der Community

Abschließend bleibt mir ein äußerst wertvoller Eindruck der NRWConf Konferenz 2012, die wieder einmal einen großen Beitrag zur konstruktiven Gestaltung der .NET- und Windows-Entwickler-Community geleistet hat.

Besonders erfreulich finde ich, dass die innere Haltung der Community auch zu neuen Technologien wie WinRT, anderen Sprachen wie JavaScript bzw. Ruby, oder besonderen Architekturen wie CQRS, sich als offen und annahmefreundlich erweist.

Wie schon in meinem Artikel "Leaving .NET" über meine persönliche Orientierung zu anderen Technologien, Plattformen und Methoden komme ich auch hier zu der Schlußfolgerung, das Alternativen per se eine Bereicherung darstellen. Mit einer vernünftigen Mischung aus innovativer Offenheit, fachgetriebener Skepsis und konstruktivem Gestaltungswillen lassen sich Alternativen auch nutzenbringend und vorteilhaft einsetzen. Das Ziel: "Turn alternatives into advantages."

Recently, I stumbled upon a code fragment from a smart developer who wrote a class to check preconditions a la Code Contracts. I personally like to guard methods to have them express explicitly the context they operate in. As I saw the code and its usage, I thought to myself: "A quite nice piece of C#". Well, be the judge for yourself:

public static class Guard {
  public static void ArgumentNotNull(Expression<Func<object>> argumentAccessor) {
    ArgumentNotNull(argumentAccessor, null);
  }

  public static void ArgumentNotNull(Expression<Func<object>> argumentAccessor, string message) {
    var compiledAccessor = argumentAccessor.Compile();

    if (compiledAccessor() == null)
      throw new ArgumentNullException(
        GetMemberName(argumentAccessor.Body), 
        message ?? string.Emtpy
      );
  }

  public static void ArgumentsNotNull(params Expression<Func<object>> argumentAccessors) {
    foreach (var argumentAccessor argumentAccessors)
      ArgumentNotNull(argumentAccessor, null);
  }

  private static string GetMemberName(Expression expression) {
    switch (expression.NodeType) {
      case ExpressionType.MemberAccess:
        var memberExpression = (MemberExpression)expression;
        var supername = GetMemberName(memberExpression.Expression);

        return string.IsNullOrEmpty(supername) ?
          memberExpression.Member.Name :
          supername + '.' + memberExpression.Member.Name;

      case ExpressionType.Constant:
      case ExpressionType.Parameter:
        return string.Empty;

      case ExpressionType.Convert:
        var unaryExpression = (UnaryExpression)expression;
        return GetMemberName(unaryExpression.Operand);

      default:
        throw new ArgumentException("The expression is not a member access or method call expression");
    }
  }
}

The usage actually reveals the elegance of this little expression tango dance:

public DateTime[] GetReferenceDates(
  string section, 
  DateTime? inception, 
  DateTime? expiry, 
  bool requireQuarterlyAlignment) {

  Guard.ArgumentsNotNull(
    () => section,
    () => inception,
    () => expiry
    );

    /* ... */
}

This isn't that bad, is it? I find this type of guarding quite readable and fluent. Plus, it just finds the parameter name in question all by itself for proper a ArgumentNullException message.

Note: I am well aware of the fact that such an approach can cause (serious) performance issues. Especially when you're using the guarded method in loops or recursion. I'm not telling you that this is the way to do guarding, I'm just telling you that I find it to be an elegant approach.

Im Interview: Kai Beck

Mein Glück ist, dass ich als Interviewpartner einen erfahrenen Agilisten gewinnen konnte, der Unternehmen von verschiedensten Ausgangssituationen aus hin zur Agilität bewegt hat: es ist der von mir hoch geschätzte Kai Beck. Seine langjährige Erfahrung an Erfolgen und auch Mißerfolgen zeichnen ihn als absoluten Kenner und Experten in diesem Gebiet aus. Es folgt ein komprimiertes Gesprächsprotokoll. Viel Spaß!

Hallo Kai. Was machst Du beruflich?

Ich berate und begleite IT-Unternehmen, zumeist vor dem Hintergrund der Prozess-, Projekt- oder Methodengestaltung. Ich bin ein großer Freund der agilen Arbeitsweise, verschließe mich aber nicht vor anderen Arbeitswegen. Für mich ist der Weg auch ein Teil des Zielbildes.

Welches sind Deine Ziele bei der agilen Software-Entwicklung?

Ich glaube ich habe nicht gänzlich unterschiedliche Ziele wie andere auch: Ich will Projekte erfolgreich umsetzen. Wenn ich es darüber hinaus auch schaffe, die Umsetzung an sich positiv für alle Beteiligten mitzugestalten, dann ist meiner Meinung nach viel erreicht. Ich gllaube das man dafür eine gute Portion stetiger Lern- und Veränderungsbereitschaft aufbringen muss. Das möchte ich bei meinen Projekten auch vermitteln.

Agile Transition wird im Allgemeinen als organisatorischer Änderungsprozess hin zur Agilität verstanden. Die allgemeine Organisationsveränderung ist in Unternehmen ein gängiges Thema. Was macht eine 'Agile Transition' im Vergleich zu anderen Organisationsveränderungen so besonders?

An sich eine spannende Frage. "Transition" ist ja eher ein technisch belastetes Wort. Es beschreibt den - meist technischen - Übergang von System A nach System B. Bei der organisatorischen, agilen Transition geht es um die psychosoziale Veränderung des "Systems". Das System kann dabei ein Individuum, ein Team, eine Abteilung oder ein ganzes Unternehmen sein.

Wie bei jeder anderen organisatorischen Änderung wird auch die agile Transition von äußeren Zwängen (z.B. Markt, Kosten, Innovation) getrieben. Das besondere bei der agilen Transition ist allerdings deren Änderungsmechanik. Idealerweise "strahlt" die agile Veränderung förmlich vom inneren des Systems nach außen.

Welches ist die erste Frage, die man sich in der Organisationsveränderung hin zu agilen Arbeitsweisen stellt?

Die Frage nach dem warum muss gestellt und geklärt sein. Das ist die fundamentale Basis jeder weiteren Wirkung. Darauf aufbauend stellt man sich die Fragen des wo Agilität überhaupt sinnvoll sein kann. Agilität ist nicht immer das Mittel der Wahl. Ich empfinde das als etwas sehr natürliches, denn schließlich ist das Agile Manifest und die Agile Bewegung aus der Software-Entwicklung im Team entstanden.

Die Kraft der Agilität ist jedoch auch, dass es Kreativität ermöglicht und sich nicht scheut, Neuland zu betreten. So sind agile Verfahren auch für Organisationsteile abseits der IT durchaus realisierbar.

Reicht es nicht, das ein Team oder eine Organisation einfach mit einer agilen Software-Entwicklungs-Methode loslegt?

Nun, ganz so einfach ist es nicht. Jede Organisation muss sich und ihre Arbeitsweisen bzw. -abläufe auch verstehen, um genau diese auch gerichtet und maßvoll einsetzen zu können. Dieses Prnzip des Verstehens ist für Teams und Organisationen nicht einfach zu erschließen, obwohl es sich absolut natürlich anhört. Man kann nicht einfach eine Organisation anhalten und sie erst einmal "ausbilden", um ihr das Verständnis zu ermöglichen. Gerade hier spielt die agile Perspektive der empirischen Erkenntnisgewinnung und adaptiven Handlungsräume eine große Rolle.

Viele Teams kümmern sich nur beiäufig um die Einbettung der agilen Verfahren in die bestehende Organisaton. Was glaubst Du, warum gerade dieser Aspekt nur wenig Beachtung findet?

Bei aller Romantik, die manch ein Agilist auch hat: Nüchtern betrachtet stösst der "innere Antrieb" von Software-Entwicklern hin zur Agilität meist schnell an seine Grenzen. Das gilt im Übrigen auch für Teams innerhalb von Organisationen. Eine "Revolution von Unten" ist nicht nur eine Prozessänderung. Vielmehr werden auch fundamentale Dinge wie das eigene Kultur- nd Werteverständnis wieder in Frage gestellt.

Diese meist komplexen Umstände und Beziehungen innerhalb der Organisation werden oft gar nicht oder zu gering wahrgenommen. Organisationsänderung ist kein starrer Maßnahmenkatalog mit fester Zielvorgabe. Organisationänderung ist vielmehr eine Änderung der Gewohnheiten - sowohl als Gruppe als auch als Individuum.

Wann ist eine Agile Transition beendet?

"Wer angefangen hat etwas zu sein, hat aufgehört etwas zu werden". Insofern ist ein "Ende von agiler Transition" de facto nicht möglich und auch nicht wünschenswert.

Als Coach habe ich natürlich Ziele und Ziellinien. So kann ich für mich festlegen, dass meine Arbeit mit Erreichung solcher Ziellinien beendet ist - aber die Veränderung an sich natürlich weiter geht. Die Eiführung von Prozessen und Veränderungen ist ja nur der sprichwörtliche Anfang. Für nachhaltige, stetige und gezielte Veränderungsbereitschaft ist meiner Meinung nach auch die "Attraktivität" des Vorgangs an sich ein Faktor. Das kann ich im Rahmen meines Wirkens beeinflussen und mitgeben.

Welche Veränderung oder Änderungsphase ist Deiner Meinung nach die wichtigste in der agilen Organisationsentwicklung?

Ich hatte es eigentlich schon erwähnt - der Anfang ist entscheidend. Gerade diese erste Klärung des wieso und warum ist eine schwierige Hürde, die man allerdings deutlich und klar nemhen muss, bevor es weitergehen kann. In der Anfangsphase ist auch das Wirken der Pilotgruppe ein wichtiges Fundament. Alle Aktivität strahlt nach außen und wird auch mit Interesse oder Neugier aufgenommen. Wer es hier schafft, diese Neugier in Faszination umzumünzen, der hat in späteren Phasen deutlich mehr Handlungsräume.

Oft wird bei der Agilen Transition die 'Kultur' in den Mittelpunkt gestellt. Wie kann man Kulturveränderung messen?

Gar nicht. Offen gesagt ist das auch gut so. Software-Entwicklung zum Beispiel dient faktisch zur Erfüllung wirtschaftlicher Zwecke. In diesem, ökonomischen Sinn ist Kultur etwas nachrangiges. Insofern ist es auch kaum verwunderlich, dass es keine Metriken dazu gibt. "Only what gets measured can get measured" - so einfach ist das.

Kultur ist nicht etwas festgeschriebenes, sondern lebendig und manchmal auch außerhalb der Norm. So eine lebendige Veränderung wie die einer Kultur kann nicht bemessen werden. Dennoch: Vertrauen und Akzeptanz sind Werte, die man leben und umsetzen kann. Alleine wenn die Umsetzung des Vertrauens in einander schon erfolgt, dann ist eine Kulturveränderung schon greifbar nah.

Wenn man in den Veränderungsprozessen stagniert - oder feststellt, dass die Organisation die agilen Verfahren nicht annimmt - was sollte man dann Deiner Meinung nach tun?

Stagnationsphasen sind nicht per se ein Warnsignal. Eine Stagnation kann auch ganz natürlich eintreten und andere Beweggründe haben. Ich denke dass es in solchen Phasen wichtig ist, ein gewisses Maß an Ruhe und Geduld an den Tag zu legen. Gleichzeitig ist es wichtig, sich weiterhin mit der Veränderung auseinanderzusetzen. So kann man z.B. die kleinen oder auch nebensächlichen Dinge anpacken.

Gibt es überhaupt so etwas wie eine 'agile Organisation'? Wenn ja, was ist Deiner Meinung nach eine agile Organisation?

Nein, es gibt natürlich keine "agile Organisation". Die "agile Organisation" ist ein Zielbild, ein optimales Modell. Und wir wissen: Ein optimales Modell existiert nicht. Eine agile Organisation ist für mich per Definition nicht existent. Organisationen können sich daran orientieren, ja sich auch danach ausrichten. Das liegt im Wesen der Agilität. Schlussfolgernd kann man Agilität per se nicht quantifizieren. Friede, Freude, Eierkuchen.

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

Der Respekt und Wertschätzung vor den existierenden Systemen, Ansichten und Methoden kommt aus meiner Sicht oftmals zu kurz. Die agilen Verfahren sind bei Leibe kein Wunder- oder Allheilmittel. Auch alternative Methoden haben ihre Berechtigung und zuweilen auch ihre Vorteile.

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

Ha! Das ist leicht: Ich wünsche mir die Agilität auf einer Augenhöhe mit anderen Verfahren in der allgemeinen Wahrnehmung. Wenn es sich in Organisationen etabliert, sollte nicht nur die "Agile Ausführung" verstanden sein, sondern im Besonderen auch das "Agile Mindset".

Vielen Dank, Kai!

Plus, this year I had the honor to hold a session about Agile Software Design at the first day of the conference. To be honest, I really was excited about it since this talk was my first I held completely in English. To even add more of a burden to myself, I decided to have two interactive exercises with the audience as well. I’m really glad and happy that everything went well. The interactive parts were exercised lively and with a good sense of fun. I also got the impression that I achieved to transport my statements and the concepts I presented for the very large part of it.

I’ll hold the same talk twice more in near future and hope I can improve a little more on a few minor things until then. Once I’m through with all presentations I’ll put the slides online.

When it comes to all the other talks and the open space sessions, it’s really a very hard task to highlight some out. Nearly all talks I attended were on a very professional and profound level. The speakers were engaged and so was the audience. I especially liked the coaching clinic and the open space.

I personally think that an open space is a must for a good conference schedule. It not only leaves room for spontaneous or audience-driven content but more often is a handy format to continue and extend conversations about topics being presented earlier on the conference.

For that matter, I pretty much liked the idea from the improuv guys who were organizing this year’s Agile World 2012 in Munich. For all slots, which by the way were themed nicely, they left over an hour of time space at the end of the day for an interactive fishbowl discussion about the topics presented. This idea turned out to be very productive and in fact was often the most valuable hour of the day.

Having this in mind, I found the open spaces at this year’s Scrum Gathering very valuable. There was literally a rainbow of topics to explore and discuss. Scrum Research, Hiring Criteria For Scrum Masters, Agile Fundamentalists, Scrum In Other Industries, Story Organization, Selling Scrum – and that’s just a tiny taste of it.

Although I couldn’t attend all sessions I wanted to – which is a regular constraint I’m hitting at such conferences – I’m all in all quite satisfied with the insights I’m taking with me after these intense days of collaborative thought, self-organized movement and global innovation.

Conclusion: Scrum Gathering 2012 in Barcelona was great!

Daraus hat sich eine handfeste Diskussion über zwei faszinierende und weite Wissenschaftsfelder ergeben: Philosophie und Mathematik. Ich werde mich hüten, jetzt viele Worte über die Verbindung zwischen Philosophie und Mathematik zu verlieren. Denn wäre es so, sähe ich mich bei weitem nicht in der Lage, meinem scheinbaren Selbstanspruch der inhaltlichen Reife in dem Maße mit fachlicher Substanz entgegenzutreten, als das sich das Ergebnis mittels der Wahrnehmung Dritter sich eben diesem Schein anzunähern vermag.

Statt dessen will ich nur eine kleine Geschichte erzählen. Meine Erzählung dieser Geschichte ist gleichzeitig auch eine mögliche Antwort auf eine Aufgabe, die ich im Anschluß an die Eingangs angedeutete Diskussion meinem Freund gestellt hatte. Bis heute habe ich eine Antwort auf diese Aufgabe vermisst. Also ist es meiner Meinung nach nur legitim, wenn ich nun selbst eine exemplarische Antwort an den Tag bringe.

Es sei noch erwähnt, dass auch mein von mir hoch geschätzer Freund mir damals eine Aufgabe gestellt hatte, die ich für mein Empfinden auch beantwortet hatte. Allerdings im starken Zweifel über die Richtigkeit des Ergebnisses - welchen ich bis Heute noch hege.

Es ist hier nicht besonders wichtig, welche Aufgabe mein Freund mir damals gestellt hatte. Gegenstand dieses kurzen Artikels ist nämlich die Aufgabe, die ich ihm damals stellte. Es ist meines Erachtens nach eine interessante Aufgabe, die es auch zu leisten vermag, einige Aspekte des Zusammenhangs von Philosophie und Mathematik hervorzubringen.

Als mein Gesprächspartner sich ganz im Hilbertschen Stil auf die Vollständigkeit mathematischer Modelle und Beweisführungen berief, um damit zum Ausdruck zu bringen, dass der Indeterminismus, den die realistisch-rationale Perspektive mit sich bringt, für Mathematiker in keinster Weise beachtens- oder nennenswert sein darf, keimte in mir schon der Gedanke zu eben jener Aufgabe, die ich ihm später stellte. Ich forderte ihn auf:

Gebe mir einen mathematisch belegten Grund, dass es sich lohnt, an Gott zu glauben.

Die Aufgabe hört sich im ersten Schritt etwas parteiisch zu Gunsten des philosophisch interessierten Zeitgenossen an. Doch auf den zweiten Blick ist meines Erachtens klar erkennbar, dass ich mit dieser Aufgabenstellung zu den Freunden der Mathematik sehr wohlwollend herangetreten bin.

Dem Conoisseur unter meiner Leserschaft wird schon aufgefallen sein, dass diese Aufgabe natürlich nicht mein eigenes geistiges Werk ist, sondern eine schon seit Jahrhunderten bekannte Aufgabenstellung, die nicht selten nach Meinung von Mathematikern als auch Philosophen als dialektischer Kunstgriff bewertet wird.

Fig 1: Blaise Pascal (1623-1662)

Doch nun zur Aufgabe an sich. Es geht also offensichtlich darum, einen mathematischen Weg zu beschreiten, der substanziell dazu beiträgt, dass der Aufgabensteller (oder ein Dritter) zu der Überzeugung gelangt, dass es lohnenswert sei, einen Glauben zu Gott zu haben. Der Urheber der Aufgabe ist zugleich derjenige, der eine besondere Antwort darauf gab. Der bemerkenswerte Logiker und Mathematiker Blaise Pascal mit seiner Pascalschen Wette lieferte einen Ansatz, der landläufig auch als "Pascalscher Glaubensbeweis" bekannt wurde.

Pascal wendet dabei relativ einfache logische Mittel an. Er stellt sowohl die Existenz von Gott als auch den Glauben an Gott zur Disposition und korreliert dies mit den dadurch (hypothetisch aufgestellten) Erwartungen der Konsequenzen der möglichen (a)theistischen Haltungen. Das Ergebnis ist eine einfache Entscheidungsmatrix, die sich einfach zusammenfassen lässt. Angenommen,

• Gott existiert und man glaubt an Gott,
  dann eröffnet der Glaube die Pforte zum Paradies im Himmel,
• Gott existiert nicht und man glaubt an Gott,
  dann wäre der Glaube umsonst und nichts wäre errungen,
• Gott existiert nicht und man glaubt nicht an Gott,
  dann wäre der Unglaube umsonst und nichts wäre errungen,
• Gott existiert und man glaubt nicht an Gott,
  dann entfacht der Unglaube das Feuer in der Hölle.

Es ist sehr deutlich erkennbar, dass sich Pascal der Statistik bedient, um argumentativ seine Überzeugungskraft zu stärken. Sein angeblicher "Glaubensbeweis" ist natürlich rein logisch betrachtet ein Zirkelschluss - und missachtet überdies auch das Problem der Unvollständigkeit der Optionen. Dennoch: Pascals Wette ist ein schillernd plakatives Exemplar der engen Beziehung zwischen Philosophie und Mathematik.

Gerade die - weder belegbare noch widerlegbare - Unvollständigkeit des Modelles, auf dem Pascal kombinatorisch korrekt die Schlußfolgerung des Vorteils an den Glauben an Gott herbeizuführen versucht, ist ein Beispiel des scheinbaren Widerspruchs von Realität und Idealität, welches sich unbeugsam mit jeder mathematischen Handlung aus dem schweigsamen Schatten jeder noch so kleinen mathematischen Operation hervorhebt.

Das Wesen der Erkenntnisgewinnung in der Mathematik - als auch die Mathematik selbst - ist damit ein Argument für den dialektischen sowie rationalen Geist, die Annahme über die Existenz Gottes im Zuge der währenden Unergründlichkeit der Dinge zumindest aufrecht zu erhalten, welches im Allgemeinen als Glaube an einen Gott in die individuelle Wahrnehmung der Wirklichkeit einen idealistischen Platz einnimmt.

Diese Souveränität des unendlich Ungewissen ist zugleich der Antrieb des Mathematikers und Wissenschaftlers. Im Sinne von Murphys Gesetz löst er ein Problem und entdeckt dabei unweigerlich weitere Probleme. Mit einem leichten Hang zum Bestätigungsfehler unterdrückt er mit dem schweren Stein des mathematisch vollständigen Beweises sein eigenes Wissen darüber, dass mithin der Weg zur Lösung des Problems ein weiteres Problem darzustellen vermag.

Doch bevor ich nun doch etwas näher an die Fachbereiche der Philosophie und Mathematik herantrete, bleibt an dieser Stelle festzuhalten: Die Fehlerfreiheit ist eine - sehr nützliche - Illusion. Gerade in der Projektion von Modellen auf die Realität tritt der kleine Spalt der Deduktion in Erscheinung und bricht das sonst so klare Licht der Logik eines Modelles in ein weites, manchmal sogar ungreifbares Spektrum von (Un-)Möglichkeiten.

Gerade diese Erkenntnis hilft meiner Meinung nach im Besonderen dem Software-Entwickler, der engagiert und professionell seine Arbeit umsetzt. Denn er wird stets versuchen, das Ideal der fehlerfreien Software zu verfolgen. Sei es formell oder informell. Jedoch sollte es für Ihn mindestens in gleichem Maße ein Wunsch sein, Software auch fehlertolerant zu gestalten. Mehr noch, für mich stellt sich in der Anwendung die Fehlertoleranz als deutlich mehrwertigeres Ziel dar.

Durch die so groß wirkende Zahl von Modellen, die in einer Software ihre Anwendung finden, ergeben sich scheinbar intuitiv eine Unmenge von potentiellen Ablaufmustern, die in Ihrer Ganzheit als ein mosaikartiges Bild der vollkommenen Logik vorstellbar sein kann. Doch statt der Anmut und Ausdruckskraft eines solchen eindeutigen und klaren Abbilds entgegnet dem Betrachter ein schemenhaftes, brüchiges Gebilde, in dem sich eine Aussage oder Intention nur vage erkennen lässt - wenn überhaupt.

Im Ergebnis lebt alle Theorie von dessen Praxis, so wie alle Theorie sich aus der Praxis erhebt. Meine Auffassung ist es, die Wirkung von Modellen zu stärken, in dem man nicht nur auf die Vollständigkeit, sondern auch auf die Unvollständikeit der Modelle eingeht.

Doch nun Schluß mit dem Geplänkel und direkt zur Sache: die Zukunft des Software-Architekten in der Software-Entwicklung. Die Zukunft des Software-Architekten ist aus meiner Sicht genau so düster wie die Zukunft des Projektmanagers vor 4 Jahren war. Der Software-Architekt hat meiner Meinung nach sowohl als Rolle als auch als Position längst ausgedient.

Für mich gibt es keine Zukunft für einen Software-Architekten.

Erfahrungswerte

Man mag mich ruhig wieder in die Schublade des Provokateurs schieben, aber ich habe meines Erachtens gute Gründe für meine Behauptung, dass der Software-Architekt als Rolle wie auch als Position ad acta gelegt werden muss.

Ich durfte in meiner Laufbahn nun drei Mal offiziell als Software-Architekt in Entwicklungs-Projekten mitwirken. In allen drei Projekten habe ich als "Architekt" völlig verschiedene Aufgaben wahrgenommen. In allen drei Projekten habe ich mich als "Architekt" auch mit anderen Erwartungen und Wahrnehmungen auseinandergesetzt. Folglich gibt es nur sehr wenige Gemeinsamkeiten der "Architekten-Rollen", die ich glücklicherweise umsetzen durfte.

In zwei Projekten hatte ich nicht nur die Rolle des Architekten inne, sondern sogar die Position. Soll heißen: ich war als Person fest für das Themengebiet der Software-Architektur eingeteilt und dafür zuständig. Ich habe mich demnach stark - ja fast ausschließlich - mit Themen wie Komponenten-Orientierung, Systemgrenzen, System-Abhängigkeiten, nicht-funktionalen Anforderungen und strategischer Entwicklung auseinandergesetzt.

Während in einem Projekt "nur" innerhalb eines Teams die Architektur-Aufgaben in meine Hände gelegt wurden, durfte ich in den anderen zwei Projekten die Architektur der gesamten Anwendung über mehrere Teams hinweg als mein Aufgabenfeld betrachten. Insgesamt habe ich einen bescheidenen Erfahrungsschatz von ca. 4 Jahren als "Architekt" in Projekten sammeln dürfen.

Mit all diesen - zugegebenermaßen relativ kurzen - Erfahrungen maße ich es mir trotzdem an, die Zukunft des Software-Architekten in Frage zu stellen.

Architektur für Alle

Ich bin der Meinung, dass ich bei all meinen Einsätzen als Architekt sehr wichtige Themen bearbeitet habe. Sowohl aus der Perspektive des Teams als auch aus der Perspektive des Unternehmens. Gerade vor diesem Hintergrund empfinde ich es als absolut notwendig, die Aufgaben der Architektur nicht auf Positionen oder Personen zu restriktieren, sondern sie als allgemeines Aufgabenfeld in der Software-Entwicklung zu betrachten.

Es ist geradezu paradox, dass man innerhalb der modernen Software-Entwicklung sich stark mit der Breite des Know-Hows auseinandersetzt, aber im Gegenzug die Architektur-Aspekte als "Elite-Aufgabe" auf einzelne Personen fokussiert. Oft reden neunmal-kluge Entwicklungsleiter von "Mitigation des Bus Factors", Pair Programming zum Know-How-Transfer und der Stärkung der Selbstorganisation des Teams durch Collective Code Ownership. Wenn es jedoch um den gefühlten "heiligen Gral" der Software-Architektur geht, will man plötzlich lieber "feste Ansprechpartner" und "dedizierte Fachkräfte" haben, um so dieser "verantwortungsvollen Aufgabe" gerecht zu werden.

Das ist in meinen Augen nicht nur paradox, sondern auch unüberlegter, geradezu eklatant herausragender Humbug. Über die näheren Gründe für solche Aussagen möchte ich hier nicht näher eingehen, sondern lediglich die diametrale Natur der eben geschilderten Situation deutlich hervorheben.

Schlußendlich sollte es in einem agilen Team meiner Auffassung nach das Ziel sein, auch die Aufgaben der Architektur gemeinschaftlich im Team umzusetzen. Das schafft eine breitere Kompetenz-Basis für die zweifelsohne wichtigen Architektur-Aspekte bei der Software-Entwicklung. Darüber hinaus ergibt sich ein gemeinschaftliches Verantwortungsbewußtsein gegenüber den Treibern und Entscheidungen zu Architektur-Aufgaben.

Eine moderne und agile Software-Entwicklung verlangt nicht nur eine Collective Code Ownership, sondern eben auch eine Collective Concepts Ownership.

Problem-Lösungs-Kompetenz

Nun, obgleich sich das eben genannte für Agilisten durchaus plausibel anhören mag, gibt es gerade bei Organisationen die sich der Agilität verschrieben haben immer wieder Probleme im Umfeld der Architektur.

Mal gibt es die Architekten innerhalb des Teams, mal gibt es sie teamübergreifend. Es kommt äußerst selten vor, dass es gar keinen Architekten gibt. Doch in allen Konstellationen kommt es zu "Schwierigkeiten", wenn es um die Architektur geht. Warum? - Die Antwort liegt in einem Wortgebilde aus drei Wörtern: Problem-Lösungs-Kompetenz.

In meinen bescheidenen Einsätzen als Architekt stand bei allen meinen Aufgaben eines im Mittelpunkt: der kompetente und professionelle Übergang eines geschäftlichen oder technischen Problems hin zu einer kompetenten und professionellen Lösung. Das bezieht sich sowohl auf die Mikro-Ebene (z.B. bedarfsgerechtes Klassen-Design) als auch auf die Makro-Ebene (z.B. Verfügbarkeit des Gesamtsystems).

Genau hier liegt auch meiner Meinung nach ein Stückweit eine Ursache für die oftmals so schmerzhafte und suboptimale Architektur-Umsetzung. Als erläuterndes Beispiel möchte ich die mittlere Makro-Ebene (z.B. Produkteigenschaften bzw. Feature-Umsetzung) mit Hilfe des agilen Management-Modells Scrum heranziehen. Scrum birgt in sich eine wunderbare Teilung: während der Produkt Owner sich um die geschäftliche Seite zu kümmern hat, obliegt es dem Team die technische Umsetzung zu verantworten.

Exakt die Trennung des "Was?" vom "Wie?" ist es, die in Scrum viele weitere Vorteile und Konsequenzen nach sich zieht. Betrachtet man allerdings diese Trennung aus Sicht der Architektur bzw. des Problem-Lösungs-Kompetenz-Gefüges, dann wird das System doch deutlich diffiziler. Während sich der PO mit der Frage des "Was?" in weiten Teilen mit dem Problemraum auseinandersetzt, ist das Team mit der Beantwortung des "Wie?" mehrheitlich agierend im Lösungsraum. Ein klassischer Software-Architekt operiert allerdings oft in beiden Feldern - also sowohl im Problemraum als auch im Lösungsraum.

Gerade deshalb versuchen viele Scrum-Teams und agile Organisationen die Software-Architekten als "Experten" ausserhalb der Scrum-Teams zu positionieren. Meistens kümmert sich dann der Architekt um ein Themenfeld und betreut im Rahmen dessen ein oder mehrere Teams. Das Team als auch der PO können den Architekten dann als technologisch orientierten Experten einbinden und von ihm sowohl beratende als auch beisteuernde Leistung anfordern.

Auf den ersten Blick sieht das nach einer gangbaren Lösung aus. Doch dabei bleibt es in aller Regel auch. Das Ergebnis der gerade geschilderten Vorgehensweise ist oftmals Konfusion, konzeptionelle Lückenhaftigkeit und ganz besonders operative Umsetzungsschwäche von strategischen Grundlagen. Das liegt meist weder am Architekten, noch an den anderen Beteiligten, sondern einfach an der Aufstellung.

Außerhalb des Teams hat der Architekt keine "Haftung zur konkreten Umsetzung", bekommt also kaum Feedback über die konzeptionelle Validität der Architektur. Darüber hinaus entzieht er sich der architektonischen Gestaltung aus der Code-Basis, die gerade bei agilen Verfahren wie TDD, BDD oder Pair Programming einen erheblichen Mehrwert liefern. Dieser Feedback-Verlust gepaart mit der punktuellen Auseinandersetzung des Übergangs von Problemraum in den Lösungsraum führt zu Inkonsistenzen im Konzept als auch zu mangelnder Stringenz in der Umsetzung.

Architektur ist ein allgemeines Anliegen

Die Lösung dieses Dilemmas ist schlichtweg die Auflösung des Software-Architekten als Rolle oder Position. Anstatt Architektur als eine "Disziplin" oder "Phase" innerhalb der Software-Entwicklung zu betrachten, gilt es Architektur als ein allgemeines Anliegen zu akzeptieren (engl: "common concern"). Schlußendlich ist es sowohl der Product Owner als auch das Team, welche sich um die Belange einer tragfähigen Architektur zur Software kümmern sollten.

Scrum bietet in dieser Hinsicht auch klare Hilfestellungen. So wird das Sprint-Planning z.B. in zwei Teile geteilt, um sowohl dem "Was?" als auch dem "Wie?" zu gleichen Teilen in der Planung gerecht zu werden. Erfahrene Scrum-Praktizierer werden wissen, das gerade das Sprint-Planning, die Estimation und das Backlog Grooming "Hotspots" für Architektur-Aspekte sind.

Es liegt auch in der Natur vieler agiler Verfahren, dass die Architektur nicht nur emergent gestaltet wird, sondern auch "quasi parallel" zu den anderen Aufgaben ins Gesamtbild eingefügt wird. Neben dem allzu prominenten TDD seien hier noch die User Stories, das Planning Poker und das CRC-Game erwähnt. Gerade erfahrene Agilisten wissen die Macht von gut durchgearbeiteten User Stories oder einem harten CRC-Game sehr zu schätzen.

Strategisches und Operatives

Einen Punkt darf man bei all den von uns sehr geschätzten kurzen Feedback-Zyklen natürlich nicht unerwähnt lassen. Viele Bereiche der klassischen Software-Architektur lassen sich in zwei Haupt-Kategorien einteilen: Die Strategie und die Operation.

Es gibt - wie auch bei allen anderen Tätigkeiten - in der Software-Entwicklung eine strategische und eine operative Ebene. Nun hat es sich mit den Jahrzehnten so manifestiert, dass die Software-Architekten auf Grund ihrer "Seniorität" und des "ganzheitlichen Blickwinkels" sich auch stark der strategischen Ebene von Software-Entwicklung zuwenden mussten, während sich der gemeine Entwickler sich mehrheitlich in einem operativen Gestaltungsrahmen wiederfand.

Wie in anderen Berufsfeldern auch, sind strategische Entscheidungen meist knifflig und besonders herausfordernd. Es liegt in der Natur der Strategie, vorausschauend, abwägend und wohldurchdacht ausgearbeitet zu werden. Es verlangt vom strategischen Gestalter meist viel Erfahrung, einen exzellenten Scharfsinn für das gegenwärtige, besonders viele Daten für das vergangene, und eine ausgewogene Antizipation für das bevorstehende.

Insofern ist das strategische Handlungsfeld der Software-Entwicklung nur unzufriedenstellend mit dem klassischen agilen Handwerkszeug greifbar. Im Gegenteil, viele Quellen zur Agilität verlieren herzlich wenig über diesen Aspekt. Das höchste der Gefühle ist da noch die Aussage, dass man eine gemeinsame Vision und die richtigen Leute für den richtigen Job zu brauchen habe.

Doch offen gesagt ist das auch gar nicht weiter schlimm. Denn: in weiten Teilen ist der strategische Handlungsbereich geschäftlicher Natur. Es gibt im Vergleich zu anderen Berufen ein gut überschaubares technisches Strategiefeld. Die üblichen Verdächtigen sind da natürlich die bekannten 3P: Platform, Programmiersprache und Produktlebenszyklus.

Aus meiner Sicht ist auch in diesem Punkt klar: der dedizierte "Stratege" Software-Architekt ist nicht notwendig, um effektive und profitable Software entwicklen zu können. Aus meiner Sicht ist hier eine ganz andere Rolle gefragt.

Es bedarf richtiger Product Owner, die sich nicht nur um die geschäftlichen Belange zu kümmern haben, sondern auch technisch-strategische Entscheidungen herbeizuführen wissen. Damit verlange ich von Produkt-Managern nicht zu viel, sondern genau das, wofür sie stehen: die strategische und operative Gestaltung des Produktes. Ein guter PM/PO lässt sich frühzeitig beraten und zieht in diesem Punkt auch die Team-Expertise mit in seine Entscheidungen ein.

Der Antimodernist

Es bleibt mir als Schlußfolgerung, dass für mich sowohl die Rolle als auch die Position des Software-Architekten in der modernen, agilen Software-Entwicklung nichts mehr zu suchen hat. Er liefert keinen Mehrwert mehr, sondern blockiert eher die gemeinschaftliche und selbstorganisatorische Arbeit in einer agilen Organisation. Der Software-Architekt ist darüber hinaus für mich eine wohl gemeinte, doch schlecht gewählte Metapher für den senioren, waisen und erfahrungsträchtigen Software-Entwickler, der sich sowohl in breiter als auch tiefer Hinsicht ausgiebig mit seiner Profession auseinandersetzt.

Die Fokussierung der architektur-relevanten Aufgaben auf eine Rolle bzw. Person innerhalb eines Teams ist ein verstaubtes Relikt einer nostalgischen Wasserfall-Ära. Für mich ist jede Organisation, welche im Team oder Projekt noch den Software-Architekten als Rolle oder Position aufstellt, schlicht und einfach im besten Falle eine "möchte-gern-agile" Organisation.

Der Software-Architekt als Funktion ist der Anti-Modernist, der Anti-Agilist, der Anti-Avantgardist in Reinkultur. Demzufolge gehört diese Rolle und Position aus meiner Sicht rigoros abgeschafft. Für mich gilt ganz klar:

Kein Software-Architekt ist besser als ein Software-Architekt.

Die Abkehr vom Software-Architekten ist für mich ein wichtiger Schritt zur Stärkung der agilen Produkt-Entwicklung. Für mich steht dabei im Vordergrund der große geschäftsrelevante Vorteil, der sich durch die Stärkung des Product Owners bzw. Product Managers ergibt.

Natürlich spielt auch die Selbstorganisations-Kompetenz des Teams eine wichtige Rolle. Im Großen und Ganzen geht es für mein Dafürhalten aber nicht nur um das Team, sondern um das Gesamt-Gefüge der agilen Software-Entwicklung als netzorientiertes Modell, welches sich von phasenorientierte Konstruktionen abgegrenzt wissen möchte.

Quo Vadis, Herr Architekt?

Es stellt sich nun unweigerlich die Frage: Was nun mit den Software-Architekten? Sind alle Architekten in agilen Projekten unbrauchbar?

Nun, eine pauschale Antwort dazu gibt es sicher nicht. Aber: es gibt Entwicklungs-Pfade für den Software-Architekt von heute hin zur agilen Kraft von morgen. In meinen Augen ergeben sich für einen Software-Architekten mehrere Alternativen, sich in der agilen Organisation einzufügen, vornehmlich als

• Software-Entwickler im Team,
• Leiter der Software-Entwicklung, oder
• Product Owner

in der Reihenfolge der "Eignung". Der wohl offensichtlichste Weg ist es, den jetzigen Architekten ins Team vollständig zu integrieren. Als erfahrener, seniorer Entwickler kann er sowohl als Mentor als auch als Lead sich in das Team einbringen und positionieren. Gerade ein "ehemaliger" Architekt kann in einem Team unglaubliche Ergebnisse erzielen, weil er durch seine gewohnten "Perspektivwechsel" und "architektonischen Überlegungen" automatisch nicht nur das Aufgabengebiet der Architektur im Team etabliert, sondern darüber hinaus die Kultur der "Interdisziplinarität" des Teams fördert.

Eine weitere Entwicklungsmöglichkeit für den heutigen Architekten ist der Übergang in das operative, teil-strategische mittlere Management als Team-Leiter, Abteilungs-Leiter oder Entwicklungs-Leiter. Gerade in produktorientierten Organisationen ist dieser Weg durchaus reizvoll, obgleich man natürlich sich als technologisch orientierter Mensch sich selbst offen die Frage stellen muss, ob man sich auch intensiver mit Management-Aufgaben auseinandersetzen möchte und/oder kann.

Ein aus meiner Sicht oft übersehener Entwicklungs-Pfad ist der hin zum Product Owner bzw. Product Manager. Im Falle desjenigen Architekten, der sich neben der technischen Expertise auch schon intensiv - vielleicht über Jahre hinweg - mit der Geschäftsdomäne auseinandergesetzt hat, macht es durchaus Sinn diesen Alternativ-Pfad ernsthaft in Betracht zu ziehen. Oft sind es gerade die fachlich und technisch starken Product Owner, die ein Produkt, ein Team, ja manchmal sogar ein ganzes Unternehmen stark positiv beeinflussen können.

Von Architekten, Meistern und Amateuren

Abschließend möchte ich noch eine persönliche Note zu der "Person" des Software-Architekten einbringen. Ich kenne mittlerweile so ca. 40-50 Personen, die explizit die Rolle, Position oder den Beruf des Software-Architekten inne halten. Sowohl aufstrebende Talente als auch jahrzehnte lang Erfahrene. Ich habe mich nie selbst als "Architekt" verstanden, hatte aber das Glück, auch als Software-Architekt viele interessante und intelligente Personen bzw. Kollegen kennen zu lernen.

Von all den Architekten die ich (mehr oder minder gut) kenne, habe ich natürlich eine individuelle Meinung. Ich kann jedoch auch offen gestehen, dass ich nahezu jeden dieser Personen als "Software-Architekten" für ungeeignet empfinde. Das liegt größtenteils an meiner persönlichen "Wahrnehmung" des Software-Architekten. Mein Bild eines Software-Architekten ist keinesfalls technisch. Nein.

Mein Bild eines personifizierten Software-Architekten ist ganz anders. Es ist derjenige Experte der Software-Entwicklung, der sich sowohl technisch als auch fachlich auf einem sehr hohen Niveau bewegt. Derjenige, der Kommunikation, Menschenführung und Prozessverständnis meisterhaft als Wirkhebel der Produktivität einzusetzen weiss. Derjenige, der ökonomische Ziele mit fachlicher Kenntnis, ethischen Werten und menschlichem Pragmatismus verfolgt. Derjenige, der lernwillig und lehrfähig als Mentor und Schüler in den Zeitgeist der Technologie und die Köpfe der Kollegen eintaucht.

Kurzum: Ein Meister der Software-Entwicklung.

Ich kenne nur eine einzige Person als Software-Architekten, der in dieses Bild des Meisters der Software-Entwicklung passt. Er ist für mich eigentlich eher ein Großmeister der Software-Entwicklung. In gleichem Maße, wie ich stolz darauf bin, mit Ihm zusammengearbeitet zu haben, bedauere ich es auch, nun nicht mehr mit ihm arbeiten zu können.

Darüber hinaus kenne ich vielleicht eine handvoll Software-Architekten, die ich als herausragende, interdisziplinäre Software-Entwickler wahrnehme. Sie bewegen sich mit geradezu unglaublicher Sicherheit in jedem Feld der Software-Entwicklung. Für mich sind diese Personen Experten der Software-Entwicklung.

Sie dürfen sich durch ihre außergewöhnliche, interdiszipliäre, ganzheitliche und tiefe Kompetenz in der Software-Entwicklung das Recht herausnehmen, sich als Experten zu bezeichnen und anderen ein professionelles Vorbild zu sein.

Der verbleibende Großteil der mir bekannten Software-Architekten sind aus meiner Sicht Software-Entwickler unterschiedlichster Kompetenzgrade. Ich kenne manche Software-Architekten, die mit den Konzepten der Polymorphie schon überfordert sind. Ich kenne einige Software-Architekten, die mysthischen Hypothesen (und "Hypes") einen höheren Wert beimessen als harten Fakten und Argumenten. Ich kenne auch Software-Architekten, die in ihrer gesamten Laufbahn nicht einen einzigen Unit Test geschrieben haben.

Natürlich kenne ich auch ein paar Software-Architekten, die Kommunikation, Teamgeist und Lernwillen zeigen, aktiv mit anderen Kollegen arbeiten und sich bzw. ihre Kompetenzen stetig einbringen. Alles in Allem also ein "breiter Durchschnitt der Software-Entwicklers".

Fazit

In der mordernen, agilen Software-Entwicklung hat die Rolle bzw. Position des Software-Architekten nichts zu suchen. Agile Organisationen haben keine guten Software-Architekten, sondern allenfalls eine gute Software-Architektur.

Die moderne Software-Entwicklung ist schnelllebig und vielseitig. Die gelebte und bewegte Interdisziplinarität von agilen Teams ist es, die ihre wahre Kraft und Produktivität entfalten lässt. Aus persönlicher Entwicklungssicht ist ein Software-Architekt kein Kompetenzbeleg mehr.

Der Software-Architekt ist die Vergangenheit, der Software-Experte ist die Zukunft.

Gerade vor diesem Hintergrund möchte ich meine z.T. noch frischen und ungeordneten Gedanken zu den gerade erwähnten Artikeln hier in einem kurzen Kommentar schildern. Vorab sei erwähnt, dass ich es für wichtig und richtig empfinde, auch Themen dieser Art offen in die allgemeine Diskussion über moderne Software-Entwicklung anzubringen.

Gutes Gefühl bei schlechter Nachricht

Im zweiten Teil über Einflüsse der positiven Psychologie in der Software-Entwicklung wird ein wie ich finde gutes und oftmals bekanntes Beispiel herangezogen. Der Projekt Sponsor wird in diesem Fall mit beschönigenden Worten und Zahlen "beruhigt", um ein gutes Gefühl über den Status des Projektfortschrittes zu haben. Gerade in phasenorientierten Unternehmen mit einem starken Linienstrang ist dieses Beispiel sicher nicht weit hergeholt.

Besonders interessant ist hier der Rückschluss, dass diese Form der Beschönigung - meist durch Projektmanager - nicht durch Absicht oder strategische Motivation umgesetzt wird, sondern instinktiv als selbstreflektierende Beruhigungsmaßnahme verfolgt wird. Im Zweifel über den eigenen Überblick, das Vertrauen zu anderen Mitarbeiten oder die Souveränität der Situation ergreift der sich in einer Drucksituation befindliche Manager zu instinktiver Herbeiführung des Gut-Gefühls, um sich wieder in eine druckmindernde und rationale Situation zu begeben.

Das dieser psychologische Wirkmechanismus zu schwierigen, wenn nicht sogar katastrophalen Projektsituationen führen kann, brauche ich hier an dieser Stelle kaum näher auszuführen. Denn ist einmal eine "Beschönigungs-Tendenz" eingeleitet, so kommt man aus dieser Verzerrung der Tatsachen kaum wieder heraus.

Der Artikel schließt mit den Worten, das es wichtig sei, das jeder im Projekt sich "gut fühlen" solle bei der Kommunikation des Projektfortschrittes - im Großen wie auch im Kleinen. Es sei wichtig, den wahrhaftigen Status des Projektes zu jeder Zeit verfügbar zu machen. Nun, dem kann ich mich natürlich nur anschließen. Doch was hier in meinen Augen fehlt sind Gedanken darüber, wie man so eine Situation des "feel good to report bad news" etablieren kann. Ich möchte hier meinen bescheidenen Beitrag mit ein paar Anregungen wagen.

Die Kultur des Scheiterns

Aus den vorangegangen Zeilen ist es schon ersichtlich, das "gut fühlen" etwas sehr subjektives ist. Dennoch lohnt es sich, gerade über die Subjektivität des guten Gefühls ein paar Worte zu verlieren. Meines Erachtens nach ist die Subjektivität ein wesentlicher Faktor - denn sie erlaubt es uns, das "gute Gefühl" zu beeinflussen. Ja, sogar ein Stückweit zu lenken.

Der erste Schritt für eine Umgebung, in der man guten Gefühls auch schlechte Nachrichten verbreiten kann, ist sicherlich die Einstellung zu Fehlern, zum Scheitern, als auch zum Konflikt. Auf all diese Punkte einzugehen würde wohl ganze Bücher füllen können. Deswegen vereinfache ich es, in dem ich es als "Kultur des Scheiterns" bezeichne. Richtiger wäre natürlich die "Kultur im Umgang mit dem Scheitern." Dennoch lasse ich es mal so flapsig formuliert stehen.

Ich denke man kann den Interessensparteien und Verantwortlichen in einem Projekt sehr gut eine positive Kultur zu negativen Nachrichten vermitteln, in dem man Ihnen die Vorzüge näher bringt. Die üblichen Verdächtigen sind hier natürlich solche Dinge wie Warnsignal, Reaktionsfähigkeit, Lerneffekt, Optimierungspotenzial und Kompetenzreflektion. Aus meiner Erfahrung lassen sich mit genügend argumentativen Beispielen dazu ökonomisch orientierte Manager überzeugen, Fehlstellungen im Projektgefüge genauer und zeitnah zu reflektieren.

Ist eine grundlegende kulturelle Basis für das Annehmen und Verarbeiten von "Unbequemlichkeiten" vorhanden, kann man den nächsten wichtigen Schritt hin zu einem progressiv-konstruktiven Projektumfeld wagen: Transparenz. Transparenz durch Visualisierung - z.B. mit einem Task-Board - ist ein ungemein mächtiges Werkzeug. Es deckt nicht nur den Status Quo auf, sondern entkoppelt die Problemstellung des Arbeitsflusses von Positionen innerhalb der Organisation. Diese "Depersonalisierung" ist wichtig, um alle Beteiligten in einen quasi "wertfreien Grundzustand" zu heben.

Aufbauend darauf lassen sich Stück um Stück viele weitere Maßnahmen ergreifen, um so eine positive "Kultur des Scheiterns" zu ermöglichen. Ist diese Kultur bei den Projektteilnehmern verankert, wird ein negativer Projektfortschritt zu etwas völlig anderem, als es im Beispiel des Artikels beschrieben wird.

Es wandelt sich von einer demotivierenden und beängstigenden Situation zu einem Signal des bevorstehenden Fortschritts. Es entsteht im Team quasi ein "Zündfunke der Verbesserung", bei dem neue Kräfte geweckt und alte Stärken herangezogen werden.

Der "glückliche" Entwickler

Doch damit sei auch an dieser Stelle genug des guten Reporting-Gefühls. Der Eingangs erwähnte dritte Teil der 'Feel Good Software Development'-Serie beschäftigt sich mit der Position des Entwicklers; primär aus Sicht eines Team-Leiters. Ich möchte jetzt nicht den gesamten Inhalt nochmals rezitieren, sondern nur anmerken, dass es sich inhaltlich auf bestimmte Themen konzentriert.

Zum Einen wäre da die grundlegende Frage der "Motivation eines Entwicklers", die im Artikel stark an das "Gut-Gefühl" des Entwicklers gekoppelt wird. Darüber hinaus wird eine Korrelation zu der Kreativleistung des Entwicklers gezogen und seine "Identifikation mit dem eigenhändig geschriebenen Code" hervorgehoben. Zum Anderen wird eine wie ich finde sehr gewagte These aufgestellt, in dem die Art und Frequenz der "Kritik am Code" das Gut-Gefühl und die Motivation des Entwicklers stark beeinträchtigt.

Wenn ich jetzt ausholen müsste, um zu beschreiben, wie aus meiner Sicht der "glückliche Entwickler" zu definieren ist, dann würde ich wohl tief durchatmen - und schweigen.

Aber ich tue es nicht. Denn auch hier zählt die Subjektivität des "Guten" und "Glücklichen". Insofern kann man wohl mit Recht behaupten, dass es den glücklichen Entwickler gar nicht gibt. Abgesehen davon empfinde ich die Aussage, dass ein Entwickler sich nur durch die o.g. Punkte gut fühle, gelinde gesagt ein Stückweit lückenhaft.

Wie dem auch sei. Ich möchte im Besonderen auf den Punkt der Art und Weise der Kritik gegenüber der Leistung von Entwicklern eingehen. Der im Artikel beschriebene Fall lässt sich nicht nur auf Entwickler, sondern auf jede Art von Leistungsbeurteilung adaptieren. Menschen, die stolz auf Ihre Arbeit sind, sind wertvolle und enthusiastische Menschen. Da ist es nur verständlich, das der Stolz "angekratzt" wird, wenn man die Arbeit kritisiert. Das ist nicht nur bei Entwicklern so, sondern auch bei Hotelfachangestellten, Universitätsprofessoren oder Gartenbaulehrlingen so.

Doch ganz im Gegensatz zum im Artikel beschriebenen "verhindern" von harscher Kritik sehe ich noch weitere Faktoren, die einer Demotivation des enthusiastischen Entwicklers entgegenwirken können. Zunächst einmal möchte ich jedoch klar und deutlich erwähnen, dass Kritik (wie auch Lob) immer wertschätzend und respektvoll herangetragen werden sollte. Das ist eine Selbstverständlichkeit, wenn man mit Menschen auf einer Augenhöhe kommunizieren möchte.

Meiner Meinung nach geht es bei der Kritikäußerung wieder um die Wahrnehmung. Man kann Kritik als destruktiv und wertmindernd auffassen, wenn nicht eine offene Kultur des Kritisierens herrscht. Wie man sich an diese "offene Kultur" herantasten kann, wird im Artikel kaum erwähnt. Das einzig angeführte Mittel hin zu einem "Feel Good Developer" ist demnach die Vermeidung von harscher Kritik. Das ist für mein Empfinden deutlich zu wenig.

Die Kultur der Kritik

Kritik lässt sich formen. Kritik lässt sich etablieren. Ja, Kritik kann und sollte man auch trainieren. Das ist auch der erste Zusatz von meiner Seite, den ich anbringen möchte. Zum Etablieren einer Basis für gestaltende Kritik ist es absolut empfehlenswert, jeden Projektteilnehmer regelmäßig in die Rolle des Kritisierenden zu stellen und ihm beim ausüben der Kritik zu begleiten. Der klassische Rollentausch-Effekt entsteht meist sehr schnell und man lernt, Kritik deutlich zu äußern, ohne jedoch ausschweifend oder sogar abgleitend zu werden.

Darüber hinaus lässt sich auch die Umgebung für Kritik schärfen. Kritik in Drucksituationen - egal ob terminlich, inhaltlich oder anderweitig - wird selten konstruktiv angenommen. Fast schon selbstverständlich sollte es sein, dass jede kritische Äußerung argumentativ gestützt werden will, um konstruktiv angenommen zu werden. Eine gute gedankliche Stütze ist dabei das "Grund vor Gegenstand"-Prinzip. Er sagt aus, das man den Grund für die Kritik möglichst dem Gegenstand der Kritik voranstellen sollte.

Übt man z.B. Kritik an einem aus der eigenen Sicht mangelhaften Code, so stellt man die Gründe für die Bemängelung vor den Mangel an sich. Statt "dieser Code ist nicht S.O.L.I.D", heisst es also eher: "Die S.O.L.I.D.-Prinzipien sind eine wichtige Komponente für qualitativen Code. Das könnten wir hier im Code noch deutlicher darstellen.".

Ein aus meiner Sicht weiterer, wichtiger Aspekt ist die Korrelation der Kritik zur Sache. Meistens wird das schon durch eine zeitnahe Kritikäußerung erreicht. Man kann aber auch andere Mittel ergreifen, z.B. eine vorangehende "Simulation des Ereignisses". Besonders hilfreich ist dies in Verbindung mit einer bewußten Verschiebung des Kontextes, um so der Personifizierung von sachlicher Kritik vorzubeugen.

Gutes Gefühl

Ich kann aus der 'Feel Good Psychology' zwar viele Anregungen mitnehmen, bleibe aber nach wie vor skeptisch. Ich empfinde die Arbeit an dem "Guten Gemeinsamen" wichtig, möchte sie aber in der täglichen Software-Entwicklung nicht zu sehr in den Vordergrund stellen.

Arbeit darf genau so wenig zu einer "Demotivations-Maschine" verkommen wie auch nicht zu einer "Feel Good-Society" ausarten. Es ist meiner Meinung nach in Ordnung, ein natürliches Spannungsverhältnis zwischen Anstrengung und Wohlgefühl anzustreben.

Menschlichkeit, Respekt und eine erwachsene Art und Weise im Umgang miteinander ist dabei die Basis. Ich empfinde eine zu starke Auseinandersetzung mit den oben genannten Punkten dabei eher als künstlich und langfristig produktivitätsmindernd. Ja, man sollte sich Geanken machen. Ja, man sollte auch das Eine oder Andere in Betracht ziehen.

Als Berater und Coach arbeite ich auch an Themen wie Kommunikation, Konflikt, Motivation und Autorität. Jedoch nicht stetig, sondern bei Bedarf. Mit konkretem Fokus und einer Portion gesundem Menschenverstand. Man muss nicht alles immer so kompliziert sehen. Es geht auch einfach.

Das so oft gesuchte "gute Gefühl" kann auch von selbst kommen, wenn man gut miteinander umgeht, sich gut versteht und gemeinsam für eine Sache arbeiten kann.

Seit meinen Artikeln zu den Zielen von Coding Dojos - als Referenz zum Nachlesen sei hier nochmals auf Teil I, Teil II und Teil III verwiesen - hat sich eben auch einiges getan. Coding Dojos haben sich inhaltlich wie auch veranstalterisch in der .NET Community etabliert. Ich empfinde das als ein sehr gutes Zeichen. Gerade vor diesem Hintergrund freue ich mich auch über Blog-Artikel, bei denen Coding Dojos als hilfreiches Mittel für Team-Weiterentwicklung angeführt werden.

Coding Dojo für Teams und Unternehmen

An genau dieser Stelle möchte ich auch anknüpfen und meine Erfahrungen und Perspektiven dazu wiedergeben. Zunächst einmal kann ich natürlich die Coding Dojos auch uneingeschränkt für Teams und Unternehmen weiterempfehlen. Ich persönlich kenne mittlerweile mehrere Unternehmen, in denen regelmäßig Coding Dojos intern umgesetzt werden. Ein Unternehmen setzt das sogar konsequent in jedem Entwicklungs-Team ein - mit beachtlichem Erfolg für Unternehmen und Entwickler gleichermaßen. (Kleine Randnotiz: Das Unternehmen betreibt Websites auf Java- und PHP-Basis!)

Das besondere an der Zielsetzung von Coding Dojos brauche ich hier eigentlich nicht mehr groß ausbreiten. Es reicht, wenn man sich vor Augen hält, dass ein Coding Dojo eine Übungsveranstaltung in lockerer Atmosphäre ist, in der jeder der Teilnehmer gleichwertig sowohl lernt als auch lehrt. Man ist als Teilnehmer also sowohl Lehrer als auch Schüler. Gerade diese Form des Erfahrungsaustausches ist eine Besonderheit, welche nicht oft genug als Vorteil (und notwendige Schlüsseleigenschaft) von Coding Dojos hervorgehoben werden kann.

Statt dessen möchte ich mich nun mehr mit den Lerneffekten eines Coding Dojo auseinandersetzen. Sie sind hilfreich, um unerfahrenen Teilnehmern eine etwas längerfristige Sicht auf Coding Dojo's zu geben. Sie können auch bei der Argumentation für Coding Dojos im eigenen Team behilflich sein.

Spass und Kommunikation

Entgegen des Eingangs erwähnten Artikels ist für mich Spass und Kommunikation kein primäres Ziel für ein Coding Dojo. Das sind Nebeneffekte, aber keine Ziele. Ein Coding Dojo hat ganz klar den gemeinsamen Weg zu besserem Code im Fokus. Also übt man, um dort hin zu kommen. Gemeinsam. Gemeinsam heisst eben auch Kommunikation. Je mehr man gemeinsam macht und löst, umso besser kann man sich gegenseitig einschätzen und verstehen. Das ist gut und wichtig. Ein Coding Dojo kann dabei auch sehr hilfreich sein.

Der Faktor Spass wird bei einem Coding Dojo meiner Meinung nach überbewertet. Das liegt z.T. an der Art und Weise, wie die Dojos umgesetzt werden - aber zu einem anderen Teil auch an der Wahrnehmung der Teilnehmer. Ich sehe mich da selbst zumindest in einer Teilschuld, denn schließlich habe ich in Dojos bei Konferenzen dazu beigetragen, dass Teilnehmer auch "Spass" mit Coding Dojos verbinden. Das ist auf den ersten Blick auch gar nicht weiter schlimm. Auf den zweiten Blick jedoch entpuppt es sich als gefährlich, weil man es als "seichte Unterhaltung" auf die leichte Schulter nehmen und den Fokus von "lernen" auf "unterhalten" verlagern könnte.

Aber: die lockere Atmosphäre und der Spass sollten auch nicht vernachlässigt werden. Sie sind eine Art von Katalysator für das Lernen. Gibt es keine lockere und offene Atmosphäre, so ist der Erfahrungsaustausch auch kaum vorhanden. Gibt es irgendwelche "Schlaumeier" oder "Emporkömmlinge", die alles besser wissen (wollen), mutiert das Dojo auch nur zu einem 0815-Workshop, statt einer Lernplattform gleichberechtigter Gleichgesinnter zu sein. Ergo: Zwischen "locker" und "zu locker" ist ein schmaler Grat. Doch "nicht locker" geht auf keinen Fall. Spass und Freude sind wichtig - aber nicht im Fokus.

Gemeinsam Besser Entwickeln

Wie schon erwähnt, kann man den Zielfokus eines Coding Dojo als "gemeinsam besser entwickeln" subsummieren. Das ist zwar weder vollständig noch präzise, aber es reicht aus, um sich ein gutes erstes Bild zu machen.

Im folgenden möchte ich meine Sicht auf die Lerneffekte von Coding Dojos wiedergeben. Sowohl das Format als auch die Werte von Coding Dojos sind es, die diese Lerneffekte ermöglichen und fördern.

Collective Code Ownership

Bei einem Coding Dojo arbeitet man gemeinsam an einer Lösung - also auch an einem Code. Dieses gemeinsame "Coding" führt unweigerlich zu einer Auseinandersetzung mit unterschiedlichen Code-Stilen. Angefangen von der Formatierung, über Namensgebung bis hin zu Design Patterns.

Diese gemeinsame Erarbeitung stärkt auch implizit das Bewusstsein der gemeinsamen Verantwortung gegenüber des Codes. Collective Code Ownership ist eines der unauffälligeren, mittelfristigeren Lerneffekte von regelmäßigen Coding Dojos.

Common Coding Guidelines

Dieser Punkt ist eng mit dem vorangegangenen verknüpft. Durch das gemeinsame Arbeiten an einem Code ergeben sich unterschiedliche "Handschriften" innerhalb des Codes, die dann in offener Runde diskutiert und begutachtet werden können.

Es entsteht ein Austausch über die Vor- und Nachteile und man kann daraufhin einen Konsens über den "gemeinsamen Stil" herbeiführen. Ein eingespieltes Dojo-Team schreibt Code wie aus "einer Feder".

Pair Programming

Viele Dojo's werden als Randori umgesetzt. Gerade dieser Modus ist ein sehr nützlicher Impulsgeber für verbessertes Pair Programming. Man lernt, wie man als Driver seinen Partner effektiv einbinden kann. Gleichzeitig erkennt man als Co-Pilot, wie man Argumente vorbereitet und darlegt, das der Partner sie auch im "Tippfluss" annimmt und abwägt.

Es gibt noch viele weitere Besonderheiten des Pair Programming, welche man bei Coding Dojos lernen kann. Gerade die öffentlichen Coding Dojos mit unterschiedlichen und neuen Teilnehmern sind in meinen Augen besonders lehrreich.

Test-Driven-Design

Eines der wohl wichtigsten Lerneffekte im Coding Dojo ist das Test-Driven-Design. Durch die direkte Auseinandersetzung mit Code werden sequentialisierte Denkmuster aufgebrochen und das System der Feedback-Schleifen antrainiert. Es werden besonders die Fähigkeiten in Anforderungsformulierung und -verifikation gestärkt, welches sich quasi sofort auf den "normalen Entwicklungsalltag" einzahlt.

Fortgeschrittene Dojo-Teilnehmer können sich auf hohem Niveau mit TDD auseinandersetzen und lernen dynamische Ordnungs- und Design-Techniken. TDD ist eines der Kern-Lerneffekte von Coding Dojos. Jedes Coding Dojo arbeitet mindestens mit TDD.

Refactoring

Stark verbunden mit TDD ist auch der Lerneffekt des Refactoring. Dabei geht es sowohl um die konzeptionelle, als auch um technische Ebene. Soll heißen: Man lernt vieles über Refactoring-Möglichkeiten und den richtigen Refactoring-Zeitpunkt.

Aber man lernt auch vieles über Refactoring-Tools und Umsetzungsstabilitäten. Erfahrene Dojo-Gänger erkennen Refactorings blitzschnell und haben ein gnadenlos gutes "Timing" für Refactorings.

YAGNI

Die Konzentration auf das Wesentliche ist bei einem Coding Dojo wichtig. Durch TDD und Babysteps lernt man vieles über Clean-Code und die SOLID-Prinzipien. Ganz besonders wird allerdings das Prinzip des YAGNI ("You ain't gonna need it") vermittelt.

Mir ist gerade bei den internen Team-Dojos aufgefallen, das dieses Prinzip sich durch die Coding Dojos regelrecht im Team "manifestiert". Das Motto des "jede Zeile muss Wert schaffen" wird deutlich gelebt und gestärkt.

Done is better than Perfect

Sowohl bei den öffentlichen als auch bei den internen Coding Dojos gibt es Zeitlimits, üblicherweise zwischen 2 und 4 Stunden. Gerade bei den internen Dojo's, die im Schnitt 2-3 Stunden dauern, kann man nach einer gewissen Zeit - sagen wir mal 20-30 Dojos später - feststellen, dass sich das Team als Ganzes fokussierter zum Ziel bewegt. Ausschweifende Grundsatzdiskussionen werden aufgeschrieben und ans Ende geschoben, manches foreach wird nicht mehr in ein eleganteres map umgewandelt.

Try before Buy

In vielen Coding Dojos wird dieser Lerneffekt kaum sichtbar gemacht und ist dennoch oftmals vertreten. Gerade bei den internen Team-Dojos werden Code Katas und Coding Dojos mit unterschiedlichen "Setups" umgesetzt.

Da wird ein neues Test-Framework ausprobiert oder aber eine andere Design-Technik. Es werden Editoren und Refactoring-Tools getestet. Ja, sogar Tastaturen und Shortcuts werden im Coding Dojo mal 'angetestet'. Als Resharper-User kennt man ja das Dilemma: "IDEA oder VS?" ist oftmals die Frage.

Wichtig ist: Im Coding Dojo ist Platz für probieren. Hier kann man sich mal aus dem Fenster lehnen und neue Dinge erforschen und gegutachten.

Team-Tactics

Zu guter letzt möchte ich noch einen weiteren Lerneffekt bei Coding-Dojos mit festen Teams erwähnen, der oftmals übersehen wird: Das Team lernt selbstständig sich taktisch zu verhalten und auch Taktiken zu verbessern. Gerade bei Teams, die schon längere Zeit Dojos umsetzen, stellt sich eine Kenntnis über die Stärken und Schwächen der Teammitglieder ein, die das Team auch entsprechend beachtet.

So werden z.B. diejenigen, die starke kommunikative Fähigkeiten haben, eher in der Anforderungsverifikation und Testformulierung eingesetzt. Mitglieder mit starken logischen oder mathematischen Skills werden eher für Lösungsraumbildung und Refactoring eingesetzt. Der "Team-Gedanke" ist ein weiterer Kern-Lerneffekt von Coding Dojos.

Do It

Als Fazit kann ich wirklich nur jedem empfehlen: lest nicht nur darüber und macht auch nicht irgendwelche "1-Mann-Dojos", in Dojos getarnte Workshops oder ähnlich komische Dinge. Besucht ein Coding Dojo in eurer Nähe! Auch wenn es kein .NET Coding Dojo ist.

So hat z.B. auch die Java-, Ruby-, Python- und JavaScript-Community viele Dojo-Freunde. Ihr könnt auch selbst ein Coding Dojo veranstalten. Intern, mit den Teamkollegen, oder aber auch mit Freunden oder Gleichgesinnten. Gerade die Teams in Unternehmen profitieren von regelmäßigen Coding Dojos ungemein. Ich kann es auf jeden Fall weiterempfehlen.

Gut ist: machen. Besser ist: regelmäßig machen. Go to Coding Dojo!

Installing the Bits

Installing Selenium looks pretty straight-forward at first sight. A quick check on the fedora repolist reveals that all we need is provided:

sudo yum info selenium-core

Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit
Installed Packages
Name        : selenium-core
Arch        : noarch
Version     : 1.0.2
Release     : 0.5.20100324svn.fc15
Size        : 1.0 M
Repo        : installed
From repo   : fedora
Summary     : A DHTML test execution framework
URL         : http://seleniumhq.org/projects/core/
License     : LGPLv2 and MIT and ASL 2.0 and GPLv2+ and (MPLv1.1 or GPLv2+ or LGPLv2+)
Description : Selenium Core is the engine of both, Selenium IDE and Selenium RC (driven
            : mode), but it also can be deployed on the desired application server.

Same goes for selenium-server, btw. Well, not really. Surprisingly, the selenium packages for fedora are quite outdated. They provide selenium version 1.02, while the current standalone server version happens to be on version 2.24.x. This is quite exceptional since fedora packages are quite on track with latest stables in general.

That's not a big stopper anyway, since downloading and using selenium is a kids task. Grab the standalone server, put in on a reasonable place like /usr/local/lib/java and create a simple start-script called selenium-server:

#!/bin/bash
java -jar /usr/local/lib/java/selenium-standalone-server.jar

plus a quick chmod a+x, and we're basically done. Starting your server with selenium-server on the command line should be fine now.

As for the python side, the python bindings for selenium are not in fedora repos. Hence we're going to PyPI and get them there with a quick

sudo pip install selenium

Voila, we're done with the installation part.

Webdriving Firefox 64bit

A subsequent check with python to verify correct operation revealed another caveat. I checked the firefox webdriver with

>>> from selenium import webdriver
>>> browser = webdriver.Firefox()

and got a nice message that the webdriver wasn't able to fire up firefox due to a "wrong ELF class: ELFCLASS32" error for libX11.so.6. A short research uncovered the issue being a known problem of selenium as described in Issue 2852. The selenium driver looks up libX11 on a wrong location.

The somewhat ugly workaround for this is to redirect to the lib64 dll with a symlink:

mv /usr/lib/libX11.so.6{,.x86}
ln -s /usr/lib64/libX11.so.6.3.0 /usr/lib/libX11.so.6

After this little hack, the firefox webdriver works as expected and the selenium testing fun finally was about to begin!

Going headless

I had written a couple of tests, I wanted to integrate them to the overall testing scripts. This actually requires to enable the tests to be headless. The're basically two options to choose from for headless testing.

The first option is to go for the (above created) server and use the RemoteDriver in the tests. This is quite straight-forward and did work very well in a few other projects I made. So I decided to check this path from within Python as well. Well, basically, it's just as easy as:

from selenium import webdriver
from selenium.webdriver.common.desired_capabilities import DesiredCapabilities

browser = webdriver.Remote(
    desired_capabilities = DesiredCapabilities.HTMLUNIT
)

Naturally, the selenium server must be running as well. In our case it's running on localhost.

It's worth mentioning that the python bindings are fairly well documented.

While this server-based approach works very well and in my experience plays well in mid-sized projects / teams, there's a second neat alternative to go headless using a virtual display like Xvfb. This is especially useful if you want to use specific functionality like capturing network traffic of taking screenshots. I came across a nice blog post describing the basic usage and want to reiterate it for my case.

In order to use Xvfb with python, Xvfb itself and pyvirtualdisplay need to be grabbed:

sudo yum install xorg-x11-server-Xvfb
sudo pip install pyvirtualdisplay

The xvfb package name may vary on other distributions. After installing pyvirtualdisplay, running a headless test with Xvfb is as easy as:

from pyvirtualdisplay import Display
from selenium import webdriver

display = Display(visible=0, size(1024,768))
display.start()

browser = webdriver.Firefox()
browser.get('http://google.com')

print browser.title

browser.quit()
display.stop()

And: it works beautifully! The nice thing about it is that switching from headless to visual mode is just changing a few lines, which can be easily parameterized. As for my simple tests on my little project, I'm using the virtual display version. It's fast enough and enables me to do some advanced checking as well.

Mein Besuch der Agile World hat mich nicht nur durch meine bescheidenen Beiträge bereichert, sondern im Besonderen durch die Beiträge der Referenten und die sehr ergiebigen Anschlußdiskussionen. Ich möchte da exemplarisch den Beitrag von Bogo Vatovec über "Skalierung von Agilität" und die Beiträge "Die Kunst der Arbeit" als auch "Konzeptionelle Integrität in Scrum" von Ulf Schneider hervorheben.

Skalierung von Agilität

In dem sehr erfrischenden und professionellen Beitrag von Bogo Vatovec konnte ich viele bestätigende und neue Impulse mitnehmen. Ich habe mich besonders bestätigt gefühlt bei den Berichten aus agilen Ansätzen innerhalb von Großunternehmen. Die Thematik der organisatorischen Granularität als auch die Schnittstellen unter den einzelnen Organisationseinheiten ist bei der Umsetzung agiler Methoden ein sehr diffiziles Aktionsfeld. Bogo hat durch Erfahrungsberichte die Komplexität großer Organisationsmechanismen gut dargestellt.

Äußerst erfreut war ich, als sowohl Kommunikation als auch die Kommunikationsform als große Erfolgsfaktoren für methodische Änderung hervorgehoben wurden. Als Agilist ist auch klar, das mit dem Begriff "Änderung" auch nur die kleinste mögliche Änderung innerhalb des bestehenden Prozessgefüges gemeint sein kann.

Denn gerade in diesem Punkt waren Bogo's Ausführungen deutlich und fundiert artikuliert: Große Unternehmen bewegen sich nicht schnell mit großen Laufschritten, sondern erreichen Änderungseffektivität durch kleine, zügige Tippelschritte.

Die Kunst der Arbeit

Obgleich mich der äußerst gelungene Vortrag "Konzeptionelle Integrität in Scrum" von Ulf Schneider sehr inspiriert und bewegt hat, möchte ich an dieser Stelle nicht näher auf den eben erwähnten, sondern auf den weiteren Beitrag "Die Kunst der Arbeit" von Ulf eingehen.

In diesem sehr anspruchsvollen Beitrag beleuchtet Ulf die Haltung zu Arbeit, deren Eigenschaften und Implikationen. Zunächst galt es die Grundhaltung zur eigenen Arbeit in drei kategorische Wahrnehmungen zu gliedern. Da wäre zunächst die Wahrnehmung der Arbeit als "Schinderei", gefolgt von der Wahrnehmung des "Handwerks" und zu guter letzt gekrönt von der Wahrnehmung der "Kunst".

Doch nicht nur die Ausführungen über die einzelnen Kategorien der Wahrnehmung waren für mich geradezu faszinierend, sondern viel mehr die Korrelation der Arbeitshaltung zu den agilen Werten. Die daraus gewonnene Schlußfolgerung war auch motivierendes Schlußwort: Ein Agilist kann, soll und wird seine Arbeit als "Kunst" wahrnehmen.

Improuv, Telefonica, NTT Data

Abschließend möchte ich noch ein paar Worte zu der Konferenz selbst verlieren. Zunächst einmal gilt für mich festzuhalten, dass das Konferenz-Format in Kombination mit den hochqualitativen Beiträgen schon als innovativ bezeichnet werden kann. Die Fishbowl-Sessions, die lange Mittagspause und der Open Space sind wahre Katalysatoren für rege Kommunikation.

Die großartige Leistung des Veranstalters improuv kann ich hier gar nicht in Worte fassen. Eine kostenlose zweitätige Konferenz dieser Güte und Qualität zu bewerkstelligen ist wahrlich schon meisterhaft. Nicht minder ist in diesem Zusammenhang der Beitrag von Telefonica einzuschätzen. Als quasi Hauptsponsor stellte Telefonica die Räumlichkeiten und das ganze "drum herum" zur Verfügung. Ich scheue mich nicht offen zuzugeben, dass Telefonica mit diesem Engagement einen sehr positiven Eindruck hinterlassen hat. Da war es für mich geradezu eine Ehre, das ich als Repräsentant der NTT Data meinen Beitrag zur Konferenz mit zwei Vorträgen und einer Motivationsrede leisten durfte. Die "Folien" zu dem Vortag Agile In Disguise sind online verfügbar.

Ich nehme von dieser Konferenz viele neue Anregungen mit. Ich habe gelernt, das man Motivation und Demotivation schon im Gesicht eines Menschen ablesen kann. Ich konnte erfahren, das ein Unbekannter mit einem Lächeln zum Bekannten werden kann. Und ich habe zu jeder Zeit gespürt, das ich noch viel lernen kann und will.

I want to catch up and comment some study results here. I'll do that in english by intent, so that my international readers have a chance to compare this with their own findings they might have in their country, region or industry.

Methodologies

First of all, let's look into what's the state of the industry on methodologies (or process frameworks). Just as a reminder, the survey was conducted in 2011.

It's interesting to point out that more than 50% of all participants use a process model based on phases. This practically means: sequential thinking - sequential doing. That's very disappointing to me, especially when you read further on and realize that not even one third is using a model which claims to be oriented on agile principles.

Agile is Fragile

Now, if we zoom in and analyze from those who claimed to follow agile principles what agile methodology they actually practice, a terrific picture is being revealed.

This figure is evidence enough that todays software industry is approaching towards a dangerous thinking that not only Scrum is Agile, but Agile is Scrum. However, what actually is shocking me is the fact that almost 30% (yes, it's really one out of three) are doing "something very agile on their own". That said, they claim to have an agile working environment and mindset without referring to existing agile methodologies. To me, this sounds like there's a large dark figure of organizations thinking that they're agile while their reality is much likely very different.

A second, very interesting figure from that study actually is the answer to following question:

What are the most valuable agile practices with regard to software quality?

The answers to this question are partly surprising:

First, the good news: 50% of all participants believe that TDD is essential for good software quality. Retrospectives are being valued high (46%), followed by (Continuous) Refactoring (40%). Despite these positive signs, there's room for improvement as well. Namely on the most important aspect of cultural effects like Collective Code Ownership (22%) and Pair Programming (30%). Those should be at least as high as TDD is right now.

Surprisingly, the most important agile practice from software quality point of view seems to be shared effort estimation (60%), most notably using Planning Poker and the like. Clean and concise user stories are of great importance, very much like daily standups are (both 50%). (Note: If you're missing Code Reviews here, don't be surprised. There's a separate survey result regarding reviews which I'll discuss later on).

Goals in Testing

Before I'll have a closer look at the interesting questions (like how is testing done in organizations nowadays), it's worth to have a short strategic perspective on testing and software quality. The topmost target in software quality testing is gain of productivity (66%), followed by the all-time favorite economical chuck-norris-sidekick-answer of cost reduction (37%). Interestingly, automation (34%) and standardization (32%) are almost as equally high valued strategic goals as cost efficiency.

Apart from these goals, another interesting fact surely is the organization of responsibility in testing. While keeping in mind that almost one out of three organizations claim to be "agile", the question of who actually is responsible for software quality testing in their organization is pretty disillusioning.

Here we are, back again in our waterfall dreams, where the project manager (57%) and test manager (51%) are being kept responsible for software quality and hence surely will have "adequate measures" to "assure" that the almighty "quality KPIs" are going to be fulfilled.

Although many testing communities love to communicate that "testing is a general concern" and needs to be adopted using a "holistic approach", the survey result speaks a very different language. Even the testers seem to favor positional (or role) responsibilities instead of just saying "the team is responsible for quality and testing". I'm not saying that no QA should be established. I'm just saying that a widespread responsibility nowadays is crucial for interdisciplinary awareness.

Testing Practices

Now let's have a closer look at the current state of affairs for testing practices. It's very interesting to me that the industry standard for estimating testing efforts is leaning more towards a complete efforts estimation model. This is a contrast to the previously mentioned responsibility perspective. From all participants, 59% stated that the testing and quality efforts are being estimated with the complete development efforts. In plain english: quality efforts are being included in all estimations.

At first sight, this seems to be a very positive thing. However, if you read the figures between the lines, it's not that much a positive sign, me thinks. Especially taking into consideration that there's quite a large number who say that quality efforts are not estimated at all (7%) or "somewhat differently" (4%). That makes me scratch my head a little. My interpretation of the large number of "quality efforts are all inclusive" statement is that most organizations don't have a deliberate process towards quality assurance activities and efforts. It's just a guess, though.

Another interesting aspect is the test systems question. Let's look at the survey results for this question:

What is the primary test system you are using for quality assurance?

I have a twofolded opinion regarding this chart. While it's very positive for me to see that 84% have a separate UAT/QA environment to have their tests running on, there's a flipside. Now imagine that almost 1 out of 4 organizations are testing their releases on live systems (24%). I don't want to imagine that, but I guess I have too. Crazy stuff.

The Art Of Testing

Let's deep dive into testing and look what core activities are being performed nowadays before the actual testing happens. Please bear in mind that more than 50% of all organizations are using a development process based on phases. This effectively means that those companies test after the development has finished.

A very weird fact, isn't it? Everybody is talking how agile they are, but nearly everybody is putting test activities at the end of the process. What a shame.

Back to the initial question at hand:

What are the primary activities prior testing?

Obviously, before testing something, 83% of all survey participants are creating test cases. Good thing. A little surprise: 60% are taking care about defining test data as well. Now, re-read this. While 83% do test cases, only 60% are performing test data definitions. This basically implies to me that 23% seem to define test cases without test data. Ok, I know this is a naive miscalculation. Still, it smells strangely to me.

One of the most interesting facts to me was test case definition. In particular, the type of test case documentation / definition. Let's take a deep breath and look at the following question:

How do you define your test cases?

The answer - honestly - made me a little sad.

The majority in the software industry just writes the test cases down in free text (54%). Got that? Need to repeat? No keyword/action based testing, no DSL's, no formalization whatsoever.

This sounds to me as if these organizations are in a testing maze. The door to verification: locked. The door to reuse: locked. The door to automation: locked! I wonder if those 54% ever heard of FIT or FITNESSE. What a horrible number.

On the other hand, 16% like to have their test cases defined the other way round: in a formal language or DSL. There's even a minority of 5% who generate test cases which were previously defined by a particular domain model. There's hope in testing land.

Done: Completion Criteria

Given we have completed all our preparations and did a nice acceptance test run. From the QA perspective, there must be some indication of what is "enough quality" to accept a given system and have it passed over to production. In order to be able to give a sensible statement for such a question, a number of quality perspectives need to be taken into account. These are widely known as Quality KPIs (KPI = Key Performance Indicator).

It's common sense here that all specified / implemented features should have a complete test case coverage to run through (75%). From code perspective, the percentage of code covered through testing (25%) seems to be important as well. Another interesting fact: 59% of all participants look at the test execution rate (number of tests performed for a particular feature) in order to quantify the quality of their software.

Once the QA testing is underway, there must be a finishing line. This is one of those things every software professional has seen at least once in his career: the deadline beads of sweat. Again, since more than half of todays software industry is testing after software development has completed, the following question (sadly) still remains important:

What are the main criteria to complete testing?

Again, I'm observing an ambivalency of quality ethics here. Shiny side: 85% of all companies prefer to have all test cases being performed. Even more, 80% think that all features have to be tested in order to complete a QA test run.

Nonetheless, there's the dark side as well: 59% (yes, it's the majority) state that their QA test is completed when the deadline is reached - regardless of the progress of their testing. Moreover, 37% of all participants just do the bare minimum, which is just to reach a given KPI or otherwise defined metric. Plus, 28% of the software industry have strict budgeting boundaries to software quality and testing.

Quality Assurance Tactics

The one and only most used strategy to quality assurance hasn't changed since ages. It's simple and effective at the same time: Reviews. Yes, just Reviews. Espacially professional testers know that a solid review culture is key to stable and sustained quality assurance. Hence, it's good to see that "only" 25% of all seem to ignore this fact.

From all of those who actually perform reviews in their projects, the subsequent question raises a few interesting aspects:

Which artifacts are regularly being reviewed in your project?

The interesting notion here in my opinion is: Albeit the most actively reviewed artifacts are the requirements, the least actively reviewed stuff is the source code itself. Second, one can observe that the more it gets 'concrete' in terms of classical phase-oriented engineering, the less it gets 'reviewed'.

From my point of view, this is quite a sad fact, since it shows that the gap between requirements and implementation both in terms of testing and in terms of domain knowledge seems to be quite large. The ultimate goal from my agile perspective would be that both requirements and code are being treated equal and subject to be reviewed at the same time.

Another interesting aspect is to focus conscious testing for different component abstraction levels:

On which component level do you regularly perform your tests?

Obviously the good news here is: All levels are recognized to be tested rigorously. At all levels, the acceptance of required testing is above 60%. Overall, I'm quite happy with the status quo of test level application. Sure, we need more unit testing. But it's a rather unspoken truth that very few developers actually really do TDD and test first.

Most of the "TDD'ers" I happen to get busy with follow the "kids slide ride" behavior pattern: At start they aim very high and mentally climb up the slide, being enthusiastic and willingly, then their motivation slides down alongside with the duration and progress of the project. In consequence, they learn that both features and thousands of tests need attention, subsequently they happen to do TDD just sparingly when they "feel it's required".

Now don't get me wrong here. I'm not saying that everything should be TDD'ed. All I want to express is that most people aim too high at start when it comes to TDD. Instead of extensively praticing TDD at start and rarely doing it at end of a project, it's better to just do a fair and well-balanced TDD activity at all time. In consequence, you get more refactorings done, feel better troughout the whole project and even achieve a better test maintenance. That's all what I wanted to say.

The next relevant set of data to extract information and insights from surely is the degree of test automation for all levels mentioned above. Data has been gathered with the following question:

How much is the percentage of automation on each test level compared to manual testing?

No big surprises here. Unit Testing is the most automated component (or unit) level, followed by the wider component boundaries. It's not even a surprise to me that the degree of automation is quite low. Only one out of four unit tests (!) are automated. I don't even want to think about all the integration and system tests being performed manually over and over again.

Automation is both from economical as well as from efficiency perspective a key technology. I think that software companies or teams denying this fact have no bright future nowadays with aspiring competitors using a fast-paced development style.

Now let's focus on a widely unspectacular perspective of testing: Error reporting. The question asked to all participants of the survey was:

If any failures are discovered during testing, how are they documented?

Undoubtedly, mostly errors are being filed in a bug or issue tracking system. What irritates me a little is that it seems that there's no momentum to further analyse or fix the failure. Surely, such activities depend on the severity and priority of the misbehavior observed. Yet, it seems to me that the focus on post-failure-discovery activities is solely on error reporting.

Quality Assurance Methods

It's a tradition in the testing field to categorize test methods into two main branches. The first, most often polished side of the methods medal is the static checking. Obviously, the flipside of the medal is the runtime checking. The survey covers both areas with a couple of interesting findings. Let's start with the static part first.

What are the mostly used static test methods in your company / project?

The number one method is the most foggy method as well: the infamous "informal" review at the desk (69%). This review can be one of the best and one of the worst methods at the same time. It highly depends on the focus, motivation, skill and professionality of the people involved.

Actually, the latter holds true for the following methods like Peer Reviews (41%) or "Walkthrough Reading" (45%). It's a little ashaming that formal reviews are not being valued that much. However, I'm personally quite happy that one out of three participants do value formal reviews (35%). I expected a much lower value.

Additionally, it's interesting to see which methods are actually performed using tools and automation techniques such as source code scanners and continuous integration services:

What methods are being supported by software tools within your project?

Ok, the figures show very clearly that there's close to no innovation and insight within this specific field of testing. While 38% percent don't use any technology at all, 54% of all participants have a coding guideline and/or style checking tool running. At least 25% do collect some code metrics using static analysis tools. That's not completely what static checking is all about for me. It's not only code style and cyclomatic complexity.

Static analysis is hierarchy and artifact analysis, cohesive components, occurance of domain-related terms and of course data structure analysis. While most of the "usual" applications drive internal or external databases, they really seldomly get reviewed and are being statically checked against. Nonetheless, the results of this particular section are quite ok, me thinks.

Let's leave the static world and concentrate on the dynamic part of test methods. This part is in particular interesting for developers and testers with a focus on automation. The first question in this section of the survey adresses the strategies of runtime test development.

What categories of dynamic tests are being developed in your company / project?

Now this is a chart! The vast majority of testing is driven by specifications (88%) and experience (79%). The combination of good specification and long experience on the domain seems to be the foundation of nowadays testing. I'm quite surprised actually that experience-driven runtime testing is that much appreciated. Undoubtedly, domain experience is a factor to be taken into account as well. Nonetheless, it's not that utterly indispensible as the figures might suppose to alarm us.

I merely expected the structure-driven tests (48%) to be on a more or less on a same level of importance as the spec-driven tests. While specifications drive the blackbox tests, the structure mostly drives the whitebox category of tests.

What specification-driven test types do you perform regularly?

Again, I'm feeling quite fine with the response to this question. We have functional tests with 82%, use case tests with 77% and boundary checks with 67% on the top, immediately followed by equivalence partitioning with 60%. To me, this is one of the best charts of the whole survey. The single notion of bitterness actually is that pairwise testing is not being used much (15%), although it actually can be a very efficient approach, especially when it comes to large combined sets or other combinatorial challenges.

That's from the blackbox side, now on to the whitebox side:

What structure-driven test types do you perfom regularly?

Well, most of the mentioned whitebox test types are most probably very familiar to those practicing TDD, BDD or do some intensive unit testing in whatsoever manner. I just want to comment on two things here. Let's start with the scary thing first this time. Almost 40% of all participants don't do any whitebox testing at all.

Now let this sink for a minute. Got it? Yes, 40%! Almost every second of the professional software engineering companies don't care how their software works. They do care about the fact that the software works as intended, but don't seem to have a lot of interest in how this actually is being accomplished. This freaking scares me.

The second notable thing here is that if there's whitebox testing, call and branch checking are well established approaches. For TDD'ers this is as usual as breathing air, but for those majority of non TDD'ers it's sort of a speciality. Hence, it's a very positive thing that whitebox tests are being performed with well-known practices.

The key to successful whitebox testing is isolation and interchange of components. That's what makes structural testing sometimes hard. However, if I were to be asked, I'd surely would emphasize the importance of structural testing as a means to establish flexible design and extensibility of a program.

Conclusion

Well, I don't want to dive into an in-depth analysis of the figures provided by the survey. Yet, let me just wrap up some facts and share some of my thoughts I had while reading the study.

First of all, it's noteworthy that testing nowadays is an overstressed word. Testing has so many meanings in software engineering - dependent on context and know-how. I think it's both necessary and useful to split the meaning of testing into two separate intentional areas.

The first area obviously is testing by means of quality assurance. This activity mainly focusses on verification of functionality. On the other hand, there's the wide area of testing by means of requirements engineering. This activity mainly focusses on the specification of functionality.

With regard to the verification activities, I perceive the current state of testing to be quite mature - both from a strategic and operational point of view. Although one can find areas of improvement, the entire view looks good to me. If I were to tell the most important areas of development, I'd bring the insufficient degree of automation as well as rarely structured test cases onto the table.

Sadly, the testing picture gets a lot darker when it comes to the specification side. My conclusion from the figures above is that testing as an equal partner of requirements engineering is not being widely recognized. That's not much of a surprise to me, since I even know a lot of self-proclaimed agilists who don't even know how testing fits into the requirements gathering view. The agile movement surely helps the whole industry to further develop this important aspect of testing. Yet, as of today very few professionals seem to follow that path.

This actually brings me to my next observation. Throughout the whole study, it seems to me as if agility finally got a serious recognition in software industry. However, I also get the impression that a lot of agile methods and agility as a holistic approach are not settled down to a level of well-known best practice. Instead a few methods seem to be practiced rather half-hearted. Even more, agility as a methodology influencing all testing activities seems to be close to non-existent. Keep in mind: the survey is from last year (2011), and we're talking about countries being on the top of the information technology society.

I want close my brief conclusion with my perception that testing seems to be still undervalued in nowadays projects. Undervalued in terms of importance to the overall project success, for sure. Plus, undervalued with respect to the activities from all project members. Regardless wether it's a testing professional, the product manager, the user interface designer or the software engineer. Testing should be recognized, valued and performed as a cross-functional concern. The sad truth is: it isn't.

Finally, I want to thank the german and swiss testing boards as well as involved university forces for their valuable and very insightful work. Please continue your amazing work! The complete study results can be found at http://softwaretest-umfrage.de - it's surely worth diving into the detailed results of the study if you want to know more about the current state of affairs in software testing.

Before I continue on describing the kata, let me give credits to the original inventor of the kata. Just the very same as it was with the incredible PickAkin kata, this kata was not my idea but the idea of smart people around me. The kata was invented specifically for this Coding Dojo by Dennis Wagner, who is a regular Dojo participant in Munich for over a year. Since the UEFA Euro 2012 Football Championship is being played this summer, he thought if it was possible to integrate this topical theme into our Dojo activities. The very successful result of this attempt is in fact the Scoreboard kata.

At our Coding Dojo, we had three teams tackling the kata and to all our surprise the kata turned to be a very good source for interesting questions and approaches within the field of OO Design, type layout and test structuring. I wholeheartedly can recommend this Code Kata to anyone. Enjoy!

Scoreboard

You are an aspiring mobile developer who just got a little product description from a very big organization to develop an App for. The name of the organization is no less than the great UEFA himself, asking you to develop an App which is able to display Scoreboards of groups for the Euro 2012 Championship. As an added feature, the App should be able to display Scoreboards for not only the actual match results, but any "custom" match results the user may enter.

As one of the first and most important things, you need to develop the scoring rules. It's crucial that the scoreboards actually display positions of teams without any error. Therefore, the official scoring system of the UEFA needs to be implemented. The scoring rules are described in detail in the official Regulations of the Euro 2012 Football Championship, Section 8.

As a nice to have suggestion, the sponsor of the UEFA would be very pleased if your implementation of the scoreboard rule system would be flexible and interchangable, so that regularatory changes or even different rules from other tournaments such as the FIFA World Championship could be applied.

To verify the core functionality of the scoreboard, you may now use the results of Group A from Euro 2012:

Matchresults

The matches listed have been played in order from top to bottom.

Scoreboard

Enjoy!

Unter den öffentlichen und persönlichen Reaktionen gab es auch ein Statement eines von mir geschätzten Coaching-Kollegen. Nach dem Lesen des Artikel schrieb er mir:

Schöne, wichtige Worte. Ich würde es aber umkehren: "Lob kann Burn-Out verhindern"

So sehr ich mich über diese warmen Worte gefreut habe, habe ich mich auch über die Umkehrung der Aussage gewundert. Das liegt an mehreren Gründen, die ich nun versuchen möchte verständlich darzulegen.

Doch vorab sei noch vorangestellt, das ich persönlich schon sehr durch "positive Umkehr-Formulierungen" geprägt bin. Das liegt einerseits daran, dass ich dieses Mittel selbst als Berater ab und an anwende, andererseits aber auch daran, dass ich selbst oft von anderen Kollegen und Beratern mit diesem Tipp konfrontiert wurde. Es ist wirklich erstaunlich, dass ich in den letzten Monaten mindestens ein Dutzend Mal darauf hingewiesen wurde, meine Aussagen doch "positiv umzuformulieren". Viel weniger erstaunlich ist allerdings, dass diese netten Hinweise fast ausschließlich von Coaches oder Beratern kamen.

Schön Sprechen

Ich finde es wichtig, das man seinem Gegenüber beim Gespräch eine kultivierte und respektvolle Wortwahl entgegnet. Das Wort Wortwahl sagt auch schon, worum es hier eigentlich geht: Die richtigen Worte finden, um die richtigen Dinge zu sagen. Oft ist es leider noch notwendig, Gesprächspartner bei Konferenzen oder anderen Unterredungen darauf hinzuweisen, das die eigenen Standpunkte mit einer achtungsvollen Gesprächskultur an Gewicht gewinnen. Insofern empfinde ich auch Hinweise zu einer bewußten Wortwahl gleichermaßen richtig und wichtig.

Bei aller Liebe zu kultiviertem Austausch kann man es aber meiner Meinung nach auch übertreiben. Mehr noch, ich empfinde eine übermäßig auf Wertschätzung orientierte Kommunikation oft als künstlich, gestelzt und wenig authentisch. Darüber hinaus kommt es viel zu oft vor, dass die angewendete "Wortakrobatik" für mich den Sinn der eigentlichen Aussage verschleiert - ja sogar verfälscht.

So ein ähnliches Gefühl beschlich mich auch, als ich den obigen Kommentar meines geschätzten Coaching-Kollegen las. In meinem Artikel zu Burn-Out und Anerkennung zitierte ich einen von mir sehr geachteten Zeitgenossen. Er sagte:

Die Leute bekommen Burn-Out, weil sie keine Anerkennung bekommen.

Eine für mich klare und direkte Aussage, die ich schnell erfassen kann. So. Und hier nun der "Verbesserungsvorschlag" meines Bekannten im direkten Vergleich:

Lob kann Born-Out verhindern.

Hört sich mindestens genau so klar und direkt an. Doch in Wirklichkeit ist es das aus meiner Sicht keinesfalls. Ich fasse diese Umformulierung der Original-Aussage eher als künstlich, verharmlosend und irreführend auf.

Abstrakte Authentizität

Meiner Meinung nach steckt in der Umformulierung ein gut gemeinter Wille, welcher sich im abstrakten Mantel der Wortakrobatik wie ein Clown zu fühlen scheint. Betrachtet man die Umformulierung mal genauer, fällt auf, das durch die Umformulierung die Aussage mindestens logisch verfälscht wurde. Während die erste Aussage klar ausdrückt, dass fehlende Anerkennung zu einem Burn-Out führen kann, verliert es kein Wort darüber, ob eine nicht fehlende Anerkennung einen Burn-Out verhindern kann.

Darüber hinaus zweifle ich persönlich auch an der Aussage. Ich glaube nicht, dass Lob als eine Präventiv-Maßnahme gegen Burn-Out darstellen kann und soll. Vielmehr ist es so, dass fehlende Anerkennung alleinig keinen Burn-Out verursachen kann und somit Anerkennung auch keinen Burn-Out verhindern kann. Die Logiker unter uns werden spätestens jetzt im Kopf den Begriff "hinreichend" in Leuchtbuchstaben grellend blinken sehen.

Oft werden ja gerade solche Argumentationen als nickelig und pingelig abgetan. Doch es ist nicht nur die Logik, die hier meiner Meinung nach ein wenig quer steht. Eine positive Umformulierung ist für mich wie eine verbale Gratwanderung, bei deren Anwendung und Umsetzung Vorsicht geboten ist. Schnell kann der konstruierte Positivismus nicht nur Akzeptanzgrenzen senken, sondern die Gesamtaussage all zu stark verharmlosen.

Auch im obigen Beispiel wurde meines Erachtens durch die positive Formulierung die Kernaussage verharmlost. Der Knackpunkt ist hier das klare darstellen des Mangels als Faktor für einen möglichen Burn-Out. Die positive Umkehrung rückt diesen Umstand so sehr in den Hintergrund, das er kaum bis gar nicht mehr erkannt werden kann. In Konsequenz steht die Verharmlosung der Aussage in positivem Wortgewand.

Exemplarische Eklatanz

Gerade diese Effekte der Verharmlosung und Verfälschung können sich in ungewollte kognitive Bahnen verlieren. So kann es in Folge des überspitzten Positivsmus zu einer Umkehrung der ursprünglich anvisierten Akzeptanzgrenzensenkung kommen. Es kann beim Empfänder nicht nur die Wahrnehmung der mangelnden Ernsthaftigkeit der Aussage entstehen, sondern sogar eine herablassende und wertmindernde Partnerprojektion verursachen.

Den Inhalt dieser komplizierten Sätze kann man natürlich auch einfacher darstellen - und das sollte man auch. Zum Beispiel so:

Eine positive Umformulierung kann dazu führen, das der Empfänger denkt, er werde vom Sender nicht Ernst genommen. Mehr noch, er könnte daraus schließen, das er nicht wichtig genug ist, um auch mit ernsten und klaren Worten wichtige Themen zu besprechen.

Das klingt doch schon deutlich besser, oder nicht? Ich denke schon. Und das ist es auch, was ich anmahnen möchte - mehr Klarheit und eine Kommunikation auf Augenhöhe, anstatt verschnörkelter und künstlicher Positivstützen, die Aussage und Authentizität verschleiern. Wir als Kommunikationspartner möchten wenn möglich vom Gegenüber als "voll" und "erwachsen" angenommen werden - nicht als ein zartes Rehlein, welches sich durch negative Sprachfetzen wie "fehlend" oder "nicht geeignet" sich verschreckt in die Mär der glänzenden Wortwolken des hellblauen Optimismushimmels zurückzuziehen wünscht.

Überspitzte verbale Positivwendung ist mir offen gesagt öfters ein Dorn im Auge. Nicht nur, weil ich selbst immer wieder angemahnt werde, "mich doch positiver" auszudrücken, sondern weil ich es immer öfters in Meetings und Gesprächen zu hören bekomme. Diese Unnatürlichkeit und gestelzte - ja oftmals schlecht gekonnte - Psychokrücke ist mir zuweilen viel zu viel des "Guten". So weichgespült, wie viele mittlerweile in unserem Job reden, reden nicht einmal Erzieher mit Jugendlichen, Eltern mit Kindern, oder sogar Großeltern mit Enkeln.

Man stelle sich nur mal vor, es stünde auf dem Schild zu einem Militärgelände nicht mehr "Nicht Betreten! Lebensgefahr!", sondern "Für ein sichereres Leben wird empfohlen dieses Gelände zu meiden.".

Optimist und Realist

Für mich ist es wichtig, sowohl optimistisch als auch realistisch an Aufgaben und Menschen heranzutreten. Obgleich ich selbst - wie schon Eingangs erwähnt - auch ab und an eine bewußt positive Formulierung einer Aussage bevorzuge, stelle ich mich mindestens genau so oft einer eben solchen Umformulierung kritisch entgegen. Im Zweifel zählt für mich die Natürlichkeit und Authentizität der Aussage.

Eine kultivierte, wertschätzende Kommunikation ist ein hohes Gut. Eine unmissverständliche und klare Kommunikation jedoch mindestens von ebenbürtigem Wert. Künstlicher Positivismus stellt sich in meiner Erfahrung öfters als ein Indiz von mangelnden Handlungs- und Argumentationsoptionen dar als ein unterstützendes Mittel für verständnisvollere Aussagen.

Lieber natürlich optimistische und offen realistische Worte, als künstlich positive und schwammig weichgespülte Worthülsen. Auf gleichermaßen respektvolle und ernsthafte Weise.

Ich werde jetzt nicht auf alle möglichen Gründe, Ursachen oder irgendwelchen Umstände eingehen, die zu einem Burn-Out führen. Das könnte ich mir auch gar nicht anmaßen, denn ein Burn-Out ist eine ernsthafte und individuell sehr stark variierende Angelegenheit. Auch der Umgang und die Behandlung eines Burn-Outs sind nicht im Vordergrund dieses Artikels. Es geht "nur" um eine ganz bestimmte Perspektive: die Korrelation zwischen Anerkennung und Burn-Out.

Anmerkung zum Anlass

Ich habe vor genau einer Woche die wahrhaftige Ehre gehabt, mit einem von mir sehr geschätzten und bewunderten Zeitgenosssen ein kurzes Gespräch zu führen. Ich kannte ihn vorher kaum - sozusagen nur vom 'Hörensagen'. Wir unterhielten uns über sein Geschäft, seine Dienstleistungen und über manche außergewöhnlichen Rahmenbedingungen seiner Aufgabe. Nichts besonderes - weder für ihn, noch für mich. Nach einer Weile redeten wir über unsere Erfahrungen und Bekanntschaften im Beruf. So kam auch das Thema Burn-Out auf den Tisch. Ohne zu zögern sagte er fest entschlossen zu mir:

Die Leute bekommen Burn-Out, weil sie keine Anerkennung bekommen.

Dieser Satz hat mich von Anfang an nachdenklich gestimmt. Ich versuchte es mir nicht anmerken zu lassen und habe ein paar Worte und meine Auffassung zu dem Thema verloren. Danach wechselte er zügig zu einem anderen Thema - womöglich, um sich selbst und mir eine tiefere Behandlung des Themas zu ersparen.

Seit diesem Gespräch habe ich öfter über diese Aussage gegrübelt und mir einige Fragen gestellt:

• Inwieweit hat mangelnde Anerkennung einen Bezug zu Burn-Out?
• Welche Konsequenzen kann fehlende Anerkennung haben?
• Warum kommt es zu mangelnder Anerkennung?

und noch einige weitere. Als ich darüber nachdachte stellte ich schnell fest, dass das Thema der fehlenden Anerkennung viel zu sehr unterbelichtet wird. Ja, irgendwie habe ich sogar das Gefühl, das es oftmals unter den Teppich gekehrt wird.

Analyse der Anerkennung

Ich möchte mich dem Thema der Anerkennung mit meinen eigenen Erfahrungen nähern. Ich habe in meinem bisherigen Berufsleben viel Anerkennung für meine Leistungen bekommen. Gerade zu Beginn meines Berufslebens hatte ich das Glück, viele Kollegen und Kunden um mich herum zu haben, die mich durch Zuspruch und Lob gestärkt haben. Manche Worte und Situationen sind heute noch sehr präsent, wenn ich mich an sie zurück erinnere.

Doch es gab auch die Kehrseite. Es gab Situationen, in denen ich hart gearbeitet und gekämpft habe - und keine Anerkennung bekommen habe. Mehr noch, ich wurde manchmal sogar für meine Leistungen und Erfolge getadelt. Ich konnte ackern, reden, kämpfen, überzeugen und leiden wie ich will, doch gerade die mir wichtigen Bezugspersonen, wie mein damaliger Vorgesetzter oder einige meiner Teammitglieder, hatten kein gutes Wort für mich übrig.

Ich räumte die Datenzugriffsschicht auf, ich verbesserte den Continuous Build, ich motivierte Mitarbeiter, ich bat Fortbildungen an und ich schrieb ein 80-seitiges Konzept über verbessertes Konfigurationsmanagement mit dem Ziel, dass sich die damalige Entwicklungs- und Systembetriebs-Abteilung einfach beser verstehen können. Ich bekam von einigen Zuspuch - doch von anderen genau das Gegenteil: Hähme, Neid und haltlose Kritik. Ich weiß durch Erzählungen Bekannter und Kollegen, dass ich mit Sicherheit nicht der einzige bin, dem so etwas - oder etwas ähnliches - in seinem Berufsleben wiederfährt.

Damals wurde mir gesagt, ich solle meine Ansprüche an mich und das Team nicht so hoch stellen. Ich sei "zu professionell" und ich solle meine Leidenschaft und Emotionen in den Hintergrund stellen. All das wertete ich nicht als Anerkennung, sondern eher als Tadel.

Mit der Bewertung möchte ich auch meine Analyse zur Anerkennung beginnen. Denn Anerkennung ist keine statische, feste Aussage. Es ist auch kein Gütesiegel, welches man verbal oder anderweitig seinem Gegenüber ausstellt. Anerkennung ist die Wahrnehmung des Gegenüber über die Bewertung seiner Leistung durch Dritte. In diesem Sinne habe ich die Bewertungen der Anderen in meinem obigen Beispiel als Tadel wahrgenommen. In wie weit das auch so gewollt wahr, möchte ich an dieser Stelle gar nicht weiter ausleuchten.

Diese Wahrnehmung des Tadels, der Gleichgültigkeit bzw. Wertlosigkeit meiner Leistungen, die ich wiederum als als hart erkämpft, schweißtreibend und angemessen betrachtete, führte zu vielschichtigen Emotionen. Ich war enttäuscht, ich war natürlich auch verärgert und gekränkt. Eine emotionale Mischung aus "euch (Kritikern) zeige ich es noch!", "war das (meine Leistung) wirklich so schlecht?" und "wieso (und für wen) mache ich das eigentlich?" machte sich in mir breit.

Wirkung der Anerkennung

Womit ich auch schon zur Wirkungsanalyse gekommen bin. Die Konsequenzen der fehlenden Anerkennung können sehr vielschichtig und vehement sein. Eine fehlende Anerkennung kann mindestens genau so prägend sein wie Lob und Zuspruch. Während oftmals nur die ernstgemeinte Anerkennung die Persönlichkeit stärkt, kann schnell ungewollte fehlende Anerkennung die Persönlichkeit schwächen.

Bei meinem oben genannten persönlichen Fall habe ich den Mangel der Anerkennung durch verschiedene Maßnahmen verarbeitet. Ich habe z.B. meine Leistungen anderen Bezugspersonen dargelegt und sie um Ihre Bewertung gebeten. Ich habe (nach langem Zögern) bestimmte Maßnahmen in anderen Teams einfach nochmal durchgeführt. Ich habe mich auch bei anderen Tätigkeitsfeldern engagiert und habe dort die Anerkennung gesucht, die ich vormals nicht bekam. Ich habe auch einigen, die mir Ihre Anerkennung aus meiner Sicht verwehrten, mit meinen Gefühlen, meiner Verärgergung und Enttäuschung konfrontiert und Ihnen gesagt, wieso ich so fühlte.

Ich kann mir noch heute kein Urteil darüber machen, ob ich nun die richtigen Mittel zur Verarbeitung gewählt habe oder nicht. Offen gesagt habe ich auch keinen Drang danach. Ich habe es nun mal so verarbeitet. Ich richte meinen Blick dort hin, wo meine Aufmerksamkeit gebraucht wird und ich diese für mich auch als richtig empfinde. Dennoch kann ich mit gutem Gewissen sagen, dass ich es für mich aufgearbeitet habe und nun in einer etwas seltsamen Art und Weise sogar Kraft aus dieser Erfahrung schöpfe.

Doch die Frage der Vehemenz und Verarbeitung der Auswirkungen fehlender Anerkennung bleibt im Raum. Es lohnt sich, hier die Brücke zu der Ausgangsaussage zu schlagen: Kann es wirklich sein, dass fehlende Anerkennung eine Ursache für Burn-Out ist? Ich persönlich denke schon, das ein starker Mangel an Anerkennung - also eine destruktive, die Seele geradezu quälende Gleichgültigkeit des Gegenüber zu der eigenen Arbeit oder Meinung - ein signifikanter Faktor für Burn-Out sein kann.

Die emotionale Erschöpfung und die sich daraus ergebende Depersonalisierung sowie der Selbstzweifel können für manche Persönlichkeiten zu einem gravierenden Problem werden. Die "Vorhut" einer solchen emotionalen Talfahrt kann sich durch starke Kritik, vehementen Druck oder fehlende Bestätigung ankündigen. Gerade eine mangelnde Anerkennung kann der Zündfunke für einen größeren emotionalen Brand werden, der sich unter bestimmten Umständen sogar zu einem Flächenbrand - dem Burn-Out - ausweiten kann.

Erkenne und Anerkenne

Nach einer ersten gedanklichen Aufarbeitung kann ich meinem Gesprächspartner von letzter Woche nur beipflichten. Ich denke, seine kurz und fast schon beiläufig gesagten Worte haben viel Wahrheit und Tiefe in sich:

Die Leute bekommen Burn-Out weil sie keine Anerkennung bekommen.

Als Fazit bleibt für mich, das ich den Wert des Erkennens und Anerkennens nun noch bewußter wahrnehme als ich es schon vorher tat. Ich bin vor einigen Monaten von einem alten Kollegen als 'Motivationsmaschine' bezeichnet worden. Dieses absolut übertriebene, so gar nicht im mein Selbstbild passende Kompliment, verstehe ich als Anerkennung gegenüber meiner eigenen Umsetzung der Anerkennung der Leistung Anderer. Ich gebe auch gerne zu: diese Anerkennung war für mich Bestätigung, Balsam und Bereicherung. Genau das ist es, was uns als Menschen hilft, motiviert und stärkt.

Es stärkt uns, Kritik anzunehmen und zu verarbeiten. Es motiviert uns, weiter wichtige und neue Wege zu gehen. Es hilft uns, anderen eine Hilfe und Stütze zu sein.

Im Interview: Christoph Mathis

Ich kann es in Worte kaum formulieren, wie sehr es mich freut, zum Thema Scrum eine der erfahrensten Persönlichkeiten Deutschlands im Interview zu haben. Er verkörpert schlechthin die Definition eines agilen Experten für Scrum als Software-Entwicklungs-Methodik. Ich bin besonders froh, dass ich mich mit keinem geringeren als Christoph Mathis von improuv über Scrum austauschen darf. Es folgt ein komprimiertes Gesprächsprotokoll. Viel Spaß!

Hallo Christoph. Was machst Du beruflich?

Ich bin Scrum Coach und Scrum Trainer bei der improuv GmbH.

Welches sind Deine Ziele bei der agilen Software-Entwicklung?

Ich helfe Teams, sich kontinuierlich zu verbessern und effektiv und zuverlässig zu liefern. Ich helfe darüber hinaus Firmen bei der agilen Transformation, um sich im Wettbewerb zu verbessern und ihren Mitarbeitern einen produktiven und angenehmen Arbeitsplatz zu bieten.

Welches sind Deiner Meinung nach die stärksten Argumente für Scrum als Entwicklungs-Methode?

Scrum schafft es meiner Meinung nach, den Spagat zwischen zwei Zielen herzustellen: Auf der einen Seite haben wir die Produkt-Entwicklung, also die Eigenschaften und Anforderungen eines Produktes, welches umgesetzt werden soll. Auf der anderesn Seite haben wir die Software-Entwicklung, also die Umsetzung von Fachlichkeiten in Software durch vielschichtige Kompetenzen, wie z.B. Design, Programmierung, Test und weiterem.

In Scrum werden diese Positionen durch den Product Owner und das Team vertreten und damit in einem Verfahren vereint. Das hat wiederum auf der einen Seite einen 'technischen' Aspekt, und andererseits einen organisatorischen Aspekt. Die technische Perspektive spiegelt sich in den Sprints als geschützten Entwicklungsraum für das Team und in dem PO als verlässliche fachliche Instanz wider. Der organisatorische Aspekt ist komplexer und kann in erster Linie in den klaren Rollen und den ausgewogenen Machtverhältnissen innerhalb des Modells erkannt werden.

Manche Teams implementieren Scrum zügig, andere wiederum scheitern daran. Woran liegt das?

Hmm, nun, das interessante an Scrum ist unter Anderem, dass es mehrere 'Ebenen' des Verfahrens gibt. Die erste, sehr sichtbare Ebene ist die Regel-Ebene. Sie ist einfach zu vermitteln und zu verstehen. Scrum hat relativ wenige und ziemlich deutliche Regeln. Dieses Regelwerk lässt sich innerhalb von 10 Minuten darlegen.

Doch dabei kann es nicht bleiben, denn Scrum hat eine weitere, tiefere Ebene, nämlich die der Prinzipien und Werte. Diese Ebene ist deutlich schwerer zu vermitteln und auch zu begreifen. Die Umsetzung dieser Ebene ist ein starker Erfolgsfaktor für Scrum und das Projekt, in dem es eingesetzt wird. Diese Prinzipien- und Wertevermittlung erfolgt meist individuell, breitet sich jedoch selbstverständlich auf das Team und die Organisation aus.

Ein schönes Beispiel ist die des "Hero-Entwicklers". In vielen Teams gibt es den senioren und außerordentlich kompetenten Entwickler, der anscheinend alles kann und schafft. Setzt dieser seine Fähigkeit für die Entwicklung des Teams ein, ist es für die Agilität des gesamten Projektes vorteilhaft. Setzt er es jedoch durch "Heldentaten" für die eigene Profilierung ein, hat das Projekt nachhaltig daduch keinen Mehrwert erhalten.

Ein weiterer, wichtiger Punkt, warum oft Scrum-Teams scheitern, ist schlicht und einfach die schlechte Technik der Software-Entwicklung. Scrum ist ein Rahmenwerk, welches keine Aussage zu Software-Entwicklungs-Techniken macht. Gerade deswegen ist es möglich, Scrum mit schlechten Entwicklungs-Methoden zu betreiben. Erfolgreich ist das allerdings nicht. Scrum kann schlechte Entwicklungs-Methoden nicht besser machen. Diese Erkenntnis setzt voraus, das man sich bei der Anwendung von Scrum auch intensiv mit agilen Software-Entwicklungs-Methoden auseinandersetzen muss.

Scrum gibt einer produktorientierten Organisation die Mittel in die Hand, einen validen Fortschrittsbericht über die Entwicklung zu erhalten und zu nutzen. Dieses sehr wichtige Element wird in Ihrer Aussagekraft allerdings stark geschmälert, wenn im Inneren des Verfahrens qualitativ ungenügend oder unprofessionell gearbeitet wird. Gerade hier ist es notwendig, dass sich Organisationen auch mit valider Bewertung und einer konstruktiven Bewertungskultur auseinandersetzen.

Ist Scrum sowie deren Rollen eine echte Alternative für die Unternehmensorganisation?

Ich bezweifle, dass Scrum sich auf einer reinen organisatorischen Ebene noch effektiv umsetzen lässt. Ich befürchte, das sich dadurch die Wirkmechanismen von Scrum als auch das Verfahren selbst verfremden können.

In gleichem Maße kenne ich allerdings Organisationsentwicklungen, die via Scrum umgesetzt werden. Ein gutes Beispiel sind sicherlich die Transition-Teams, die sowohl auf einer organisatorischen als auch auf einer technischen Ebene an der Einführung von Scrum in die Organisation arbeiten. Naturgegeben sieht man bei solchen Anwendungen schon adaptive Veränderungen des Scrum-Verfahrens.

Z.B. wird manchmal die Rythmik im Transition-Team justiert (Stichwort: Daily), in anderen Fällen werden auch traditionelle Change-Management-Elemente mit eingebracht. Das ist sehr individuell von der Organisation und Kultur des Unternehmens abhängig. Ein weiterer, schwieriger Umsetzungspunkt für Scrum innerhalb der Organisationsentwicklung ist z.B. die Definition of Done. Bei einem technischen Projekt ist die DoD meist sehr klar greifbar. In der Organisationsentwicklung ist eine Definition of Done jedoch wesentlich schwieriger zu erfassen.

Gibt es klare Indizien, wann und wo Scrum nicht angewendet werden sollte?

Nun, es gibt natürlich auch viele Bereiche, in denen Scrum als Mittel gar nicht gebraucht wird. Ein schönes Beispiel ist die Schadenssachbearbeitung bei einer Versicherung. Dort gibt es wenig Variations-Spielräume in der Sache und wenig Entwicklungsbedarf. Solche Prozesse funktionieren mit SixSigma sicherlich ganz gut.

Es gibt darüber hinaus auch Bereiche, die eine starke Ereignisorientierung aufweisen. Man kann sich dabei z.B. ein Wartungs- oder Support-Team vorstellen, welches stark unvorhergesehene Ereignisse wie Geräteausfall oder ähnliches abwickelt. Solche Arbeitsbereiche werden meiner Meinung nach auch wenig von Scrum profitieren können.

Scrum ist viel eher für Situationen und Projekte geeignet, in denen komplexe Systeme erstellt werden müssen, in denen kreative Leistung und Lösung gefordert wird, in denen man Stück für Stück Produkte neue erschaffen oder weiter gestalten möchte.

Unlängst erfreut sich neben Scrum auch Software-Kanban steigender Beliebtheit. Wo liegen Deiner Meinung nach die größten Unterschiede beider Verfahrensmodelle?

Scrum beruht auf einem zweigeteilten Planungsmodell. Der Produkt Owner treibt und definiert das Produkt; das Team ist in der Verantwortung der Umsetzung mit allen Facetten. Obgleich die Planung hier zweigeteilt ist, ist sie sehr klar und dediziert im Verfahren verankert. Es ist meines Erachtens wichtig zu erkennen, das diese Verteilung der Planungsverantwortung gegenseitige Autonomie im jeweiligen Bereich nach sich zieht. Während der Product Owner die Autonomie der Produktgestaltung inne hält, hat das Team die Autonomie über die Produktumsetzung.

Kanban lässt sich jedoch auch völlig ohne die Autonomie des Teams umsetzen. Das ist nicht zwingend der Fall, kann aber durchaus so umgesetzt werden. Diese Möglichkeit eröffnet den Anwendern von Kanban, den vertrampelten und morschigen Pfad des Command and Control zu gehen. Neben den Agilisten unter den Kanban-Anwendern gibt es zu meinem Bedauern viele Kanban-Anwender, die keineswegs agil arbeiten oder arbeiten wollen. Das ist gerade für die Agilisten eine schwierige Gratwanderung.

Scrum-Expertise und agiles Know-How werden heute oftmals mit Trainings erlangt und mit Zertifizierungen belegt. Gibt es Deiner Meinung nach auch andere oder sogar bessere Vermittlungs- bzw. Bildungswege?

Scrum im speziellen sowie die agilen Verfahren sind in diesem Punkt schon speziell zu betrachten. Ein pures Training alleine ist oftmals ziemlich ineffizient. Es kann ein Anfang sein, aber nicht viel mehr.

Das Wort Know-How verrät es schon, das es um zwei Aspekte geht. Zum einen gibt es den Aspekt des Wissens, zum Anderen natürlich den Aspekt des Könnens. Das Volumen und die Tragweite des Wissens ist bei Scrum relativ klein. Der Rahmen des Könnens ist bei Scrum verglichen zum Wissensanteil deutlich größer.

Gerade vor diesem Hintergrund ist ein "begleitender Ansatz" wie das Coaching meiner Meinung nach deutlich effektiver. Coaching und Beratung als begleitende Maßnahme ist für mich eine nachhaltige und greifbare Methode zur Vermittlung der agilen Verfahren und Werte.

Das ganze Themenfeld der Zertifizierung ist meiner Meinung nach nur ein Nebeneffekt, der sich mit dem steigenden Anwendungsgrad von Scrum etabliert hat. Ich sehe hier im Besonderen die Personalabteilungen und deren Bewertungsstrategien als Treiber für Zertifizierungen. Das mag durchaus für manche Organisationen als Bewertungsindiz dienen. Ich bin jedoch der Meinung, das für die Organisation die effektive Umsetzungsfähigkeit und Erfahrung deutlich wichtiger ist und daran richte ich auch meine Trainings aus.

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

Für mich ist das gemeinsame Ziel als Team sowie das Vertrauen in die Personen und Fähigkeiten innerhalb des Teams ein sehr wichtiger Faktor. Natürlich gibt es noch weitere Dinge, wie z.B. Kompromissfähigkeit, gute Qualität bei der Software-Technik und kontinuierlicher Verbesserungswillen.

Aus der Perspektive der Etablierung bzw. Gestaltung eines Scrum-Teams würde ich die "Ermächtigung des Teams" stark in den Vordergrund stellen. Das Fundament für eine erfolgreiche Gestaltung eines Scrum-Teams sind zwei wesentliche Dinge: Erstens, Empower the Team, und zweitens, Continuous Improvement. Das ist meiner Meinung nach unabdingbar.

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

Wir als Agilisten sind der Inspektion und Adaption verpflichtet. Dementsprechend können und sollten wir immer nach Lücken und Fehlern Ausschau halten. Das ist individuell und ändert sich auch mit dem Reifegrad und dem Zug der Zeit.

Als konkrekte Aufgabe für die Agilität betrachte ich die deutlichere Herausarbeitung und Kommunikation, dass agile Verfahren und Software-Entwicklung nicht mit Massenfertigung und Produktion in Verbindung zu bringen sind, sondern vielmehr an eine menschenorientierte, kreative Entwicklung und Leistungserbringung gekoppelt sind. Gerade die Orientierung am Menschen - die postindustrielle, humanistische Haltung - ist für mein Empfinden als essentiell zu werten und von uns noch stärker in dem Vordergrund zu stellen.

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

Respekt und Vertrauen. Ich wünsche mir, das Erwachsene sich als Erwachsene behandeln.

Vielen Dank, Christoph!

Weitere Interviews der Serie "Der Agilist"

• Agile Coaching mit Christian Dähn
• Agile Games mit Thorsten O. Kalnin
• Agile DevOps mit Andreas Mandi-Beke
• Agile und Kanban mit Markus Andrezak
• Agile Management mit Kai Simons
• Agile Engineering mit Björn Rochel
• Agile Education mit Ole Pophal
• Agile Scrum Master mit Bettina Ruggeri

I use my Tablet (which is an ExoPC) more like a netbook. I take a wireless keyboard with me and most often use it for research, writing and mails. I'm using Fedora 16 on this device for almost a year now and have had a great experience so far. Plus, I was happy to experience that Gnome 3 fits very well for my scenario.

Pre-Upgrade

Upgrading Fedora is very easy. If you look at the upgrade guide, it's essentially as easy as sudo yum install preupgrade and subsequently executing preupgrade. Really, there's no big deal about it. However, if you happen to plan an upgrade as well, be sure to backup your system and read the docs.

My upgrade procedure went very smooth. The initial boot to F17 was fast and appeared to be without any issues. F17 welcomed me with the usual login screen, I logged in and everything seemed to just work fine. Except one thing: it was slow. And by slow, I mean really slow. Even typing in terminal lagged a few seconds behind the actual keystroke. It seemed to me as if UI performance went back to early 90's.

Gnome3 Software Rendering

After a few minutes of investigation using the usual

lspci | grep VGA
glxinfo | grep renderer

I found out that the new Gnome-Shell software rendering has caught me. The Fedora Test Page for this feature unveiled very useful information for my further analysis. It seemed as if the Intel drivers which happily worked with F16 no longer worked with F17. Obviously, such a theory sounded strange to me, so I further went down to analyze Xorg.0.log.

The analysis uncovered the real issue: The log clearly stated that the intel driver couldn't be loaded:

(EE) Failed to load module "intel" (module requirement mismatch, 0)

While digging deeper into the logs and simultanuously researching the web for similar cases, I found that the X-Servers version (1.12) was not the version for which the failing intel driver was compiled (1.6). It obviously was the case that the driver was not suitable for the new X version. I checked the currently installed driver package with

sudo yum list installed xorg-x11-drv-intel

and to my own surprise I saw that the package was still from F16's repositories! The interesting thing was, that an update check with

sudo yum check-update

didn't reveil that I'm on an old (non-working) driver. From my naive perspective I assume that it might be a little leak in the overall upgrade process. The solution however was quite simple:

sudo yum remove xorg-x11-drv-intel
sudo yum install xorg-x11-drv-intel
sudo shutdown -r now

After the reboot I got full hardware accelleration back and the UI responded quick and smooth again.

Despite this little glitch, I've had a very pleasant upgrade experience and almost everything was still where I expected it to be. In my opinion Fedora is a great distro with a very clean organization of the overall system. I'll upgrade my other systems soon as well and keep being a happy user of Fedora.

From 'mental' (or practical) perpective, I'll change my blog gradually from a non-directed, spontaneuous blabbing, ranting and random thought disposal instrument towards a more topic-oriented and directed writing. I won't start to write technical or theoretical articles or books. I want to keep my blogging small since I like the concept of small, chewable chunks of information for a specific topic.

Second, from technical perspective, I'm going to completely change the platform and infrastructure of my website (again). I'll move off from WordPress and use a static website generator instead. I don't have much interactive content or even applications. Hence, static webpages serve my purposes quite well. However, there's one little dynamic thing I have until now. You guessed it already, it's my blog comment functionality.

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 decision. 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 und kompetente 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 ein vielerorts erfolgreiches agiles Methodenwerk. Darüber hinaus erscheint es dem Neuling bzw. Interessierten auch als ein einfaches Methodenmodell, 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!

Weitere Interviews der Serie "Der Agilist"

• Agile Coaching mit Christian Dähn
• Agile Games mit Thorsten O. Kalnin
• Agile DevOps mit Andreas Mandi-Beke
• Agile und Kanban mit Markus Andrezak
• Agile Management mit Kai Simons
• Agile Engineering mit Björn Rochel
• Agile Education mit Ole Pophal

Das spannende an der Konferenz ist sicherlich die Größe und Qualität. Es gibt de facto keine größere (und für mein Empfinden auch beeinflussendere) Community-Konferenz für das Microsoft & .NET-Umfeld als die .NET Cologne. Schaut man sich die Agenda der Konferenz an, weiß man auch, warum.

Ich habe bei der diesjährigen Konferenz einen kleinen Beitrag leisten dürfen, in dem ich meinen Vortrag über die Geheimnisse der Continuous Integration "CI-Secrets" gehalten habe. In diesem Vortrag bin ich in klaren Worten auf die offensichtlichen und etwas versteckteren Kniffe eingegangen, die man methodisch und technisch anwenden kann, um eine Continuous Integration erfolgreich im Team zu manifestieren. Meine drei Haupt-Themen-Gebiete waren dabei Kultur, Automatisierung und Qualität.

Ich möchte jetzt nicht weiter auf die einzelnen Talks oder Eindrücke eingehen, die ich bei der Konferenz sammeln konnte. Viel mehr liegt es mir am Herzen, dem Veranstalter, Sponsoren, Vortragenden und Teilnehmern für eine absolute Spitzen-Konferenz zu danken. Ganz Besonders die Veranstalter und Sponsoren haben es ermöglicht, nun mittlerweile über mehrere Jahre der .NET Community eine Konferenz im Stile einer Top-Wissenstransfer-Plattform bereitzustellen.

Die .NET Cologne ist unverzichtbar - für ausnahmslos jeden, der im .NET Software-Development tätig ist. Ich kann es jedem .NET Enthusiasten oder Interessierten uneingeschränkt empfehlen.

Ich hatte schon letztes Jahr einmal über meine Eindrücke zum .NET Day Franken geschildert. Der Artikel hat nicht einen Hauch von Aktualität verloren. Aus gutem Grund. Es waren alle "F" des letzten Jahres wie gewohnt vertreten. Mehr noch, in diesem Jahr legte der Veranstalter sogar noch eine Schippe drauf. Ich sag' nur: Film, Fantasie, Freunde und Fit.

Ich kann zu den einzelnen Talks leider nicht sehr viel sagen. Aus gutem Grund. Ich konnte nur an einer einzigen Session teilnehmen - und das noch nicht mal vollständig. Dafür schäme ich mich auch. Aus gutem Grund. Denn die Session - es war die "Wie ruiniere ich ein Scrum-Team"-Session von Udo Wiegärtner - war qualitativ und quantitativ sehr anspruchsvoll.

Ich bin mir sicher, dass auch die anderen Sessions in der gleichen Liga gespielt haben. Ich durfte mich glücklich schätzen, meinen "Amigo Agilo"-Beitrag zu der Veranstaltung beizusteuern. Der Mut und das Vertrauen des Veranstalters kann an dieser Stelle gar nicht hoch genug gelobt werden. Diese Jungs sind einfach eine Klasse für sich.

Mein eigener Eindruck war jedoch, dass sich das Vertrauen des Veranstalters in mich nicht ausgezahlt hat. Aus gutem Grund. Ich war mit meinem Talk ziemlich unzufrieden. Ich hatte das Gefühl, dass ich mein Thema nicht vollends und klar jedem Teilnehmer vermitteln konnte. Insofern bin ich doppelt dankbar, dass sich meine Zuhörer mir erbarmt haben und trotz meiner Schwierigkeiten Interesse an meinem Thema gezeigt haben. Danke vielmals, ich weiß es sehr zu schätzen.

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.

In diesem siebten Interview der Interviewserie der Agilisten widme ich mich dem Punkt der Agile Education. Das hört sich Anfangs etwas komisch an, in einer Zeit, in der Wissen und Informationsmanagement als "Kulturbestandteil" wahrgenommen werden. Doch Bildung & Lehre werden im Software-Entwicklungs-Arbeitsleben leider zu oft auf Konferenzen und Zertifikate reduziert. Eine sehr eindimensionale Sicht wie ich finde.

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!

Weitere Interviews der Serie "Der Agilist"

• Agile Coaching mit Christian Dähn
• Agile Games mit Thorsten O. Kalnin
• Agile DevOps mit Andreas Mandi-Beke
• Agile und Kanban mit Markus Andrezak
• Agile Management mit Kai Simons
• Agile Engineering mit Björn Rochel

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 souverän in unerkannt akribischer Ingenieurs-Manier und hinterlässt dabei einen leichtes, harmonisches Klangbild. 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!

Weitere Interviews der Serie "Der Agilist"

• Agile Coaching mit Christian Dähn
• Agile Games mit Thorsten O. Kalnin
• Agile DevOps mit Andreas Mandi-Beke
• Agile und Kanban mit Markus Andrezak
• Agile Management mit Kai Simons

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!

Weitere Interviews der Serie "Der Agilist"

• Agile Coaching mit Christian Dähn
• Agile Games mit Thorsten O. Kalnin
• Agile DevOps mit Andreas Mandi-Beke
• Agile und Kanban mit Markus Andrezak

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 might already guessed from my official dislike of Googles V8 JS engine that E4X is not implemented in V8 (and thus doesn't exist for node.js). Apart from SpiderMonkey (of course), Rhino and AS3 have E4X suppport. Oh, E4X is an official ECMA Standard, by the way.

<rant>

I'm no JavaScript guru. However, I wrote quite a few applications in JS, ranging from "the good old web-apps" up to device-specific apps. Even a small data visualization app using XULRunner. I used node.js in the past (for file/image processing purposes) and I use it today as well. Now, the thing is: With this (little) experience of a year with Node, I'm starting to really dislike the whole concept of Node.

I'm not going to dive in further about my reasons for not liking it. I just want to lay out that in my opinion the fact that Node is based on v8 and is forcing me to stick to inappropiate server-side single-threaded event-loop is a big step back to stampcard engineering.

It shouldn't be that way. JavaScript has a vibrant community and with the rise of HTML5 JavaScript really can become a serious (albeit sick) option for frontend engineering. Even more, recent developments on JS really show that we generally head to the right direction.

</rant>

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.

Im Interview: Andreas Mandi-Beke

Es ist mir eine besondere Freude, dass ich für diese besondere Perspektive der agilen Software-Entwicklung mit Andreas Mandi-Beke einen Agilisten und erfahrenen agilen DevOp gewinnen konnte. Andreas ist als waschechter DevOp bekannt für agile Umsetzung von IT-Produktion und Administration. Dieses Interview mit Andreas ist das dritte in meiner Forschungsreise durch die Welt der Agilisten. Es folgt ein komprimiertes Gesprächsprotokoll. Viel Spaß!

Hi Andreas! Was machst Du beruflich?

Andreas: Ich administriere seit einigen Jahren schon vielerlei Systemumgebungen für einen großes Webportal - AutoScout24 - und habe auch besonderen Spaß daran. Ich finde es einfach spannend, effektive Lösungswege für administrative Herausforderungen in kurzer Zeit umzusetzen. Im Web musst Du am Ball bleiben.

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

Andreas: Puh... ich würde aus meiner DevOp-Sicht zwei wichtige Ziel-Aspekte anbringen: die Continuous Integration und das Continuous Deployment. Das ist meiner Meinung nach ein wichtiger Punkt, denn genau diese Methoden ermöglichen es, Verantwortung über die Software wieder mehr dorthin zu tragen, wo sie entsteht: beim Software-Entwickler. Ich als DevOp kann das durch eine gute CI/CD unterstützen und es konsequenterweise als eines meiner Ziele ins Auge fassen.

Welchen Herausforderungen muss sich ein agiler DevOp im agilen Umfeld stellen?

Andreas: Ein DevOp ist ein Chamäleon. Er muss flexibel und anpassungsfähig sein. Ein DevOp vereint zwei ganz entscheidende Perspektiven: Einerseits ist es wichtig, im Systembetrieb Zuverlässigkeit und Stabilität zu gewährleisten. Andererseits ist es wichtig, offen für Veränderungen zu sein und sie sogar zu fördern. Das ist Elementar für einen agilen DevOp: er fördert die Veränderung, in dem er es in seiner Person und Position ermöglicht, Stabilität und Veränderung im Einklang zu halten.

Was ist für einen DevOp wichtig im Zusammenspiel zwischen Software-Entwicklung und Operations?

Andreas: Das wichtigste ist und bleibt die Kommunikation. Wir sind alle Menschen und können ein gemeinsames Verständnis nur durch enge und intensive Kommunikation erreichen. Ich als DevOp habe andere Perspektiven auf die Software als ein Software-Entwickler - und das ist auch gut so. Das entscheidende ist die Abstimmung hin zu einem gemeinsamen Zielbild. Für mich ist Kommunikation ein fundamentales Erfolgskriterium.

Wie integriert sich ein DevOp denn in ein agiles Team?

Andreas: Meine Vorstellung von einer guten Teamintegration fängt nicht bei anderen Teammitgliedern an, sondern beim DevOp selbst. Er soll in der Lage sein, aktiv auf alle Beteiligten zugehen zu können und sich über den Stand der Dinge zu informieren. Hier ist wieder der Punkt der Kommunikation. Es ist immens wichtig, das ein DevOp einen Teil seiner Zeit für diese "Informationsbeschaffung" und den "Austausch" investiert, um dann im Ergebnis Klarheit über die Software aus Betriebssicht zu erlangen.

Wie stellt sich ein agiler DevOp den "idealen" agilen Software-Entwickler vor?

Andreas: Na ganz klar: er ist agil. Das entscheidende Kriterium ist für mich das "Leben" von Agilität. Es geht um die aktive Gestaltung des Fortschritts. Meiner Meinung nach ist es nicht nur damit getan, dass sich ein Entwickler mit neuen Technologien auseinandersetzt, sondern es in den richtigen Kontext für seine Aufgabe rückt. Die Fähigkeit, sich für Veränderung und Fortschritt einzusetzen ist für mich auch wichtig.

Ja, und ein weiterer, sehr wichtiger Punkt ist für mich die Kompromissfähigkeit. Ob es nun ein agiler DevOp, agiler Entwickler oder agiler Tester ist. Kompromisse sind das Mittel des Einzelnen, einen gemeinsamen Weg zu gehen.

Was ist in einem agilen Team Deiner Meinung nach entscheidend?

Andreas: Neben der Kommunikation ist für ein agiles Team meiner Meinung nach die Ausgewogenheit und Interdisziplinarität wichtig. Ich kann Software nicht ohne Tester, DevOp, Product Owner, Designer oder Entwickler umsetzen. Gleichzeitig sollte das Team in der Lage sein, "sich selbst zu fordern". Also: die Selbstorganisation sollte meiner Meinung nach auch eine stetige gemeinsame Zielsetzung und Zielumsetzung enthalten.

Man sagt oft, Scrum und Systembetrieb - das passt nicht so zusammen. Stimmt das?

Andreas: Wer sagt das? Ich sage: es ist durchaus möglich. Kommunikation und Kompromissfähigkeit vorausgesetzt. Scrum hat natürlich die "Erstellung von Software" im Fokus, während der Systembetrieb sich eher um den "Betrieb von Software" beschäftigt. Insofern ist die Systembetriebssicht etwas breiter. Aber: Ich finde es als DevOp besonders wichtig, gerade in dem Erstellungsprozess einer Software schon involviert zu sein und mitzuwirken. Das Ergebnis aus Betriebssicht ist eine wesentlich bessere Wartungssicht auf die Software.

Welches sind die größten Herausforderungen für einen Administrator, der sich zu einem agilen Operator oder sogar DevOp entwickeln möchte?

Er muss sich von der klassischen Administration verabschieden - definitiv. Das denken innerhalb des "Systems" und innerhalb einer "Systemlandschaft" ist da nicht mehr ausreichend. Er muss sich und seine Sichtweise erweitern auf die Dinge, die vor und neben seiner Systemlandschaft passieren. Er sollte aufgeschlossen gegenüber der Software-Entwicklung, gegenüber der Produkt-Entwicklung und den vielen anderen Facetten von Software sein.

Die Rolle des DevOp ist hier auch klar: Er ist der Enabler im Sinne der "Verwirklichung" - also dem eigentlichen Einsatz - von Software. Es muss dem DevOp klar sein, dass diese Schnittstelle ein heißer Punkt in der gesamten Software-Produktions-Kette ist. Je cooler er ist, umso besser kann er auch seine Aufgabe wahrnehmen.

Die entscheidenden Merkmale für einen DevOp sind für mich Aufgeschlossenheit, Kommunikationsfreude und Professionalität.

Was sollte ein agiler DevOp nicht tun - oder können? Wo sind die Grenzen eines DevOp?

Das Rollenverständnis sollte schon ausgeprägt sein. Was ich damit meine ist, dass er schon seine Kernkompetenz im Fokus halten sollte. Ein DevOp kann sicherlich gute Skripte für die Automatisierung schreiben. Das versetzt ihn aber noch lange nicht in die Lage, sich auf die Kompetenzen eines Software-Entwickler einzulassen. Das gleiche könnte ich jetzt auch für die anderen Rollen - also Tester, Usability-Experte o.ä. - anbringen. Die Konzentration auf das Hauptaufgabengebiet ist wichtig.

Auch denke ich, dass er nicht damit aufhören sollte, sich und seine Arbeit zu reflektieren. Ein stetiger - manchmal durchaus kritischer - Blick auf die eigene Arbeit und Arbeitsweise ist wichtig. Also: nicht mehr reflektieren sollte er definitiv nicht tun.

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

Das ist eine gute Frage. Ich glaube, das der Gemeinschaftsgedanke nach wie vor schwierig und lückenhaft ist. Es kann immer wieder vorkommen, das man in das alte "Schubladen-Denken" der "Verantwortlichkeiten" und "Zuständigkeiten" zurückfällt. Gerade, wenn Dinge mal nicht so rund laufen. Aber genau dann ist es wichtig, die gemeinschaftliche Verantwortung zu stärken und im Team zu agieren.

Es fehlt meiner Meinung nach auch ein konkreteres auf einander zugehen. Zum Beispiel können wir DevOps uns auch mit dem Produkt-Management austauschen. Im Gegenzug finde ich, kann auch der aktive Austausch von anderen Abteilungen oder Perspektiven zum Systembetrieb gefördert werden. Ich fände es schön, wenn sich z.B. auch ein Produkt-Manager für die Software- und Systemwartung mehr begeistern könnte.

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

Puh. Ich würde mir wünschen, das es nicht mehr möglich wäre, Unternehmen "ausbluten" zu lassen. Die uneingeschränkte und geradezu unantastbare Macht des puren Kapitalismus lässt sich für mich nicht mit dem agilen Gedanken vereinbaren. Kooperation und Kapitalismus müssen in einem ausgewogenen Verhältnis zueinander stehen. Es kann für eine zukünftige agile Arbeitswelt nicht richtig sein, dass eine einzige Kraft oder Meinung alleinig Bestand haben kann. Vielmehr wünsche ich mir für jedes Unternehmen und jeden Mitarbeiter ein gemeinsames Wirken für ein gemeinsames Ziel - auf einer ausgewogenen und partnerschaftlichen Basis.

Vielen Dank, Andreas!

Weitere Interviews der Serie "Der Agilist"

• Agile Coaching mit Christian Dähn
• Agile Games mit Thorsten O. Kalnin

The syntax of the PHP lambda will be very familiar to JavaScript developers, actually:

$plus = function($x, $y) { return $x + y; };

That's pretty straight forward. However, PHP's syntax is still unique. This mainly is reasoned by the fact how closures are implemented in PHP. Let's look at a function with a closure:

$canprint = function($x) { return $x % 2 == 0; };
$printseq = function($a, $z) use ($canprint) { 
  for ($i = $a; $i < $z; $i++)
    echo $canprint($i) ? $i : '-';
};

$printseq(1, 10);

Developers coming from other languages (such as JavaScript) may scratch their had a little on the explicit function($x) use ($y) {} syntax. However, it's quite interesting that you pretty easily can get used to it.

The reason why I post this (nearly 3 years old) language feature of PHP is not only that I find it to be used rarely. I for one think that anonymous functions are very important to any language and enable the developer to build a whole new class of elegant solutions. Let me illustrate this with a classic example showing you that anonymous functions can be called recursively as well:

$fib = function($x) use (&$fib) { return $x>1 ? $fib($x-1)+$fib($x-2) : $x; };

Suppose you have a file with some configuration settings:

$admin_active = true;
$admin_startpage = "dashboard";
$admin_usemru = true;
$admin_persist_flag = F_ACTIVE | F_CHANGED;

$user_active = true;
$user_startpage = "listissues";
$user_usemru = false;
$user_persist_flag = F_ACTIVE;

$dashboard_layout = "simple";
$listissues_layout = "self";
$markissue_layout = "detail";

Let's further on suppose that you should write a small snippet to administer and configure these settings from above. It's pretty obvious that settings are grouped by role in the settings file (see $admin_startpage and $user_startpage). If you were to build up a configuration panel where the current role would be able to change his own dashboard layout, how would you solve that? Assume that you have variable with the current role in action, something like

$active_role = "admin";

How to read and change the page layout of the startpage of the currently logged on role?

With meta-variables, the solution is almost a one-liner:

$active_startpage = "${active_role}_startpage";
$page = ${$active_startpage}; # "dashboard" if role is "admin"
$active_layout = "${page}_layout";
$layout = $$active_layout

The second line is the "trick" called meta-variable. The line actually reads: "Take the value of $active_startpage as the name (or symbol) of the variable I want to access the value of". The same applies to the 4th line, but this time with the more lightweight $$-syntax. Let's look at an even simpler example to get meta-variables illustrated:

$mode = "effect";
$menu = "mode";

echo $$menu;  # prints "effect"
echo $$mode;  # prints "shade"
echo $$$menu; # prints "shade"

The above example shows the power of meta-variables quite nicely. Despite the lightweight $$-syntax (which is more commonly used than the complex curly syntax), the example shows that the level of nesting is not limited to a simple meta-lookup. In fact, meta-variables (in theory) can be nested arbitrarily. I for one haven't ever used a deeper nesting than 3, though.

Meta-variables can be very useful for code/variable introspection and simple metaprogramming tasks. However, it should be kept in mind as well that the power of meta-variables can be very dangerous as well, especially when it is combined with user input. That being said, meta-variables should be used with great caution.

Im Interview: Thorsten O. Kalnin

Mein Interview mit Thorsten ist das zweite bei meiner Erkundungstour durch die Welt der professionellen Agilisten. Nachdem es im ersten Interview um Agile Coaching allgemein ging, möchte ich mit Thorsten in den speziellen Bereich der sog. "Agile Games" eintauchen. Es folgt ein komprimiertes Gesprächsprotokoll. Viel Spaß!

Hallo Thorsten! Meine überraschende Einstiegsfrage: Was machst Du beruflich?

Thorsten: Ok. Mein Name ist Thorsten Oliver Kalnin, ich lebe mit meiner Hündin in Köln und bin freiberuflicher Coach und Trainer. Neben Life & Business Coaching bin ich auch als Lean & Agile Coach, Empirical Experience Facilitator und StrategicPlay Facilitator tätig. Darüberhinaus gebe ich auch Scrum Trainings und Teambuilding Workshops.

Was sind Deine Ziele bei der agilen Software-Entwicklung?

Thorsten: Ich habe zwar meine Wurzeln in der Softwareentwicklung, konzentriere mich jedoch bereits seit einigen Jahren speziell auf das Thema Agiles Mindset, Coaching und Trainings. Mein Ziel ist es, Individuen, Teams und Unternehmen mit kreativen Techniken und Verfahren zu unterstützen, damit diese ihr Potenzial erweitern und ausschöpfen können. Ob es sich dabei um Softwareentwickler, Autobauer oder Manager handelt ist mir ehrlich gesagt zweitrangig.

Für mich steht der Mensch als Individuum im Mittelpunkt meines Handelns. Nur ein ausgeglichener, glücklicher und kreativer Mensch macht als Person ein Team stark. Stichwort: systemisches Denken und Handeln.

Du bist als agiler Coach besonders bekannt und engagiert im Bereich Agile Games. Worum geht es bei "Agile Games"?

Thorsten: Dafür möchte ich etwas ausholen. Zunächst bevorzuge ich den Namen Empirical Experience. Dahinter verbergen sich Agile Games, Serious Play sowie Training from the back of the room.

Bei Empirical Experience geht es um das Lernen. Egal, ob es sich um Werte, Wissen, Techniken oder ähnliches handelt. Das Prinzip besteht darin, ein sicheres Umfeld für den Teilnehmer zu schaffen in welchem die natürlichen Gesetze vorübergehend außer Kraft gesetzt werden. Dies gibt Menschen die Möglichkeit auszuprobieren, Fehler zu machen und dadurch effektive Lerninhalte sich zu eigen zu machen in dem man sie erfährt.

Denke z.B. an einen Piloten der in einem Flugsimulator kritische Situationen wieder und wieder übt um mit ihnen zu recht zu kommen und in der realen Welt dann anwenden kann. Das ist Empirical Experience.

Wofür bzw. an welchen Punkten kann man Empirical Experience konkret im Arbeitsalltag einsetzen?

Thorsten: Das ist nichts für jeden Tag. Schließlich geht es im Alltag ja darum, seine Arbeit zu machen. Vielmehr geht es darum, sich kontinuierlich weiter zu entwickeln - und dafür ist Empirical Experience gedacht. Man kann es z.B. sehr gut in Retrospektiven anwenden; Stichwort: Kaizen & Teambuilding.

Für wen sind SeriousPlay-Strategien geeignet, für wen eher nicht?

Thorsten: Ich denke SeriousPlay ist für jeden geeignet! Ob es sich dabei um Entwickler, Marketing-Fachleute oder Autobauer handelt ist zweitrangig. Es geht darum, die Arbeitsumwelt interessanter zu machen, zu lernen und ganz im Besonderen dabei viel Spaß zu haben. Ich gebe z.B. auch SeriousPlay Workshops für Innovatoren im medizinischen Bereich.

Eine Anmerkung noch zu "SeriousPlay":

Ich verwende den Begriff Empirical Experience, da bei der Verwendung des Namens SeriousPlay oder Agile Games viele Menschen leider "dicht" machen. Manche denken dabei es geht um "Zeitvertreib" und "Zeitverschwendung", wenn sie die Begriffe "Games" oder "Play" hören. Das war für mich der Grund, vor gut einem Jahr diese Begriffe mit Empirical Experience zu substituieren. Hörten manche z.B. "Games" oder "Play", kam oft: "ich habe keine Zeit zu spielen, ich muss arbeiten" - ohne dass ihnen dabei bewusst war, dass dadurch wichtige, strategische Lerninhalte vermittelt oder Strategien entwickelt werden können.

Welche (potentiellen) Nachteile siehst Du beim Einsatz von Empirical Expirience bzw. SeriousPlay?

Thorsten: Nachteile sehe ich im Prinzip keine. Im Gegenteil. Menschen entgeht eine wichtige Entwicklung und ich bin der Meinung dass dies noch weiter wachsen wird. Ich sehe den Nachteil eher darin, Empirical Experience zu vermeiden!

Welches ist das für Dich das wichtigste Charaktermerkmal für Agilität?

Thorsten: Das ist eine gute Frage. Ich bin gar nicht sicher, ob ich das mit einem Charaktermerkmal beschreiben kann. Wichtig ist, open-minded zu sein, keine Angst vor Veränderungen zu haben und sich selbst immer wieder in Frage zu stellen. Agilität ist für mich ein Mindset, eine Art Lebensweisheit, eine Philosophie.

Die Offenheit für Fehler und als Konsequenz aus Fehlern zu lernen möchte ich noch anfügen.

Wie motivierst Du Dich für Deine Arbeit mit Menschen und Unternehmen?

Thorsten: Durch die Arbeit selbst. Wenn ich einen Workshop, ein Training oder ein Coaching gebe, mache ich mir vorher sehr viele Gedanken. Wenn ich merke, dass meine Arbeit Menschen nicht nur beruflich sondern auch privat weiterbringt, sie Spass daran haben - dann ist das schon eine gehörig große Motivation.

Darüber hinaus gehört aber auch ein privater Ausgleich. Selbst Spaß zu haben, in die Natur zu gehen, in die Sauna, Laufen und Musik machen, einfach seinen Leidenschaften zu fröhnen.

Wie wichtig ist es eigentlich, "aus Fehlern zu lernen" - und - wie kann man das lernen?

Thorsten: Es ist enorm wichtig aus Fehlern zu lernen und das muss man sich auch eingestehen können. Viele Menschen versuchen perfekt zu sein - und genau da liegt das Problem. Perfektion ist der Killer von Weiterentwicklung. Ich möchte dazu Seth Godin zitieren: "Deliver early, fail early, inspect and adapt, deliver again." und wenn möglich in kleinen Zyklen. Stichwort: LeanStartup.

Wie man das "Fehler machen" lernen kann ist eine gute Frage. Ich denke man kann es nicht wirklich lernen. Es ist mehr eine Frage der Einstellung. Z.B: Wie kann ich Fehler anfangen zu feiern? Denn schließlich lerne ich aus ihnen.

Man muss verstehen dass Fehler das Prinzip der Natur sind. Der Mensch ist aus vielen Fehlern entstanden. Das Prinzip der Evolution. Wie Edison einst so schön gesagt hat als er die Glühbirne erfand: "Ich habe nicht 2000 mal versagt, ich habe lediglich 2000 Wege erkundet die nicht funktionieren für das was ich vorhabe".

Beispiel Brainstorming oder Blue Sky Thinking: In dem ich sehr viele Ideen kreiere - ohne diese bei der Erstellung zu bewerten - setze ich Potenzial frei. Am Ende sind vielleicht 50 Ideen durchgespielt. Davon sind 40 vermutlich unsinning, 7-8 durchschnittlich aber eben auch 1-2 sehr gute und außergewöhnliche. Nur wenn ich es zulasse, Fehler zu machen kann ich innovativ und kreativ sein.

Wie siehst Du die Zukunft der modernen Software-Entwicklung?

Thorsten: Die Software-Entwicklung hat heute einen starken Einfluß auf die gesamte Arbeitswelt. Wir befinden uns mitten in einem Wandel, der noch viele Veränderungen mit sich bringen wird. Die Zukunft liegt in der nachhaltigen Wandelung der Industriegesellschft hin zu einer Arbeitsgemeinschaft, in der Individualität und Bedarfsdeckung im Einklang stehen.

Die Software-Entwicklung - und damit auch die Agilität - ist dabei schon ein Vorreiter. Man kann sicherlich sich auf das agile Manifest beziehen. Aber auch hier geht es weiter. Agilität entwickelt sich auch. Stichwort: Wikispeed.

Der zukunftsweisende Weg ist dabei, dass wir unsere Arbeitswelt auf Individualität ausrichten können. Es ist sehr gut machbar, ökonomisch, kooperativ und individuell zu agieren.

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

Thorsten: Es fehlt leider noch vielerorts das Verständnis darüber, was Agilität bedeutet. Ein aktuelles Beispiel ist sicherlich die z.T. sichtbare Reduktion der Agilität auf Scrum. Das ist Schade. Man darf sich da auch nichts vormachen. Gerade im Management-Bereich gibt es dort eine schwierige Ausgangssituation. Das mittlere Management hat oftmals Probleme, mit den neuen Freiräumen und Gestaltungsoptionen umzugehen. Sei es für sich selbst oder für Ihre Abteilung.

Insofern kann man sagen, dass gerade dieses Verständnis erreicht werden muss, in dem man Offenheit fördert und die Kommunikation stärkt. Das ist und bleibt ein Prozess, dem wir uns widmen müssen.

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

Thorsten: Mein Wunsch ist einfach: Ich wünsche mir, dass jeder, egal wer einen Coach zu rate ziehen kann. Es geht da gar nicht um den Coach selbst, sondern vielmehr um die Erkenntnis, dass ein Partner, der von außen eine Sicht und ein Feedback beitragen kann, ein entscheidender Faktor für die Erarbeitung eines Lösungsweges sein kann. Es ist egal, ob jetzt ein Entwickler, ein Postbote, ein Manager oder ein Coach einen Coach bekommt. Entscheidend ist das Feedback und die professionelle Begleitung.

Vielen Dank, Thorsten!

Weitere Interviews der Serie "Der Agilist"

• Agile Coaching mit Christian Dähn

In C#, generics are a powerful thing. Most C# developers use them day by day, especially with collection types like List<T> or Dictionary<K,V>. From Time to time, even custom generic types can be very useful. I've seen quite a lot of custom generic types recently on a project where a generalized request/response communication system is being implemented for component interaction.

Consider you want to create a pair of values for a simple configuration file model, something like a setting with a name and a value. One might easily implement this with the (quite) new Tuple<F,S> type:

var foreground = new Tuple<string,string>("foreground", "blue");
var background = new Tuple<string,ConsoleColor>("background", ConsoleColor.Yellow);
var errorlines = new Tuple<string,int>("errorlines", 3);

Quite straightforward, isn't it? I'm even glad we have type inference since C# 3 and can use var here, otherwise we would've got the type repetition like this:

Tuple<string,bool> supressErrors = new Tuple<string,bool>("suppressErrors", false);

I think you agree with me that this is quite a lot of code to write just to create a pair of values. Not that nice. But there's one already mentioned feature to the rescue: the almighty type inference can help out again.

C# not only supports type inference for variable initialization but as well generic method invocation. I'm sure that the enthusiatic C# developers already know that this feature actually exists. Yet, it's being used quite rarely. To benefit from this feature, we could write a static construction method for the above Tuple<K,V> example:

public static class New {
  public static Tuple<K,V> Tuple<K,V>(K k, V v) {
    return new Tuple<K,V>(k, v);
  }
}

And then - immediately - a reworked version of the above settings example looks much more readable - and intuitive:

var foreground = New.Tuple("foreground", "blue");
var background = New.Tuple("background", ConsoleColor.Yellow);
var errorlines = New.Tuple("errorlines", 3);

Far better me thinks! Notice that the generic types for the tuple are being inferred from the parameters of the Tuple<K,V> static method. Yet another tiny gimmick with quite a big value delivered in terms of readable and concise code. All thanks to type inference.

Most recently, I see code similar like the following quite often:

IEnumerable<Customer> GetCustomersOfSection(Filter regionAndNameFilter) {
  IEnumerable<Customer> customersOfSection = new List<Customer>();
  IEnumerable<Customer> customers = GetCustomersBy(regionAndNameFilter);

  if (customers != null) {
    customersOfSection = 
      from customer in customers
      where customer.Section == SectionCode.InnerCirle
      select customer;
  }

  return customersOfSection;
}

Now, what's wrong with that code? - Nothing. However, it could've been written a little smarter. The obvious non-nicety here is the check on customer as well as setting the default on customersOfSection. How can we improve this? The answer is two little question marks plus a little gimmick. Yes, I'm talking about the null-coalescing operator ??.

Let's see how this micht look like in action:

IEnumerable<Customer> GetCustomersOfSection(Filter regionAndNameFilter) {
  return
    from customer in GetCustomersBy(regionAndNameFilter) ?? Enumerable.Empty<Customer>()
    where customer.Section == SectionCode.InnerCircle
    select customer;
}

Now this looks a lot more concise, isn't it? The trick obviously is the usage of the inline null check ?? Enumerable.Empty<Customer>(). It makes the if clause fall apart into two little question marks. Plus, the overhead of variable declaration is gone. If we now extract this construct to a little extension method, suddenly the code starts to tell us the whole story:

IEnumerable<Customer> GetCustomersOfSection(Filter regionAndNameFilter) {
  return
    from customer in GetCustomersBy(regionAndNameFilter).OrEmpty()
    where customer.Section == SectionCode.InnerCircle
    select customer;
}

public static class Extensions {
  public static IEnumerable<T> OrEmpty<T>(this T t) {
    return t ?? Enumerable.Empty<T>();
  }
}

Well, looks better, isn't it? I for one think that the code is now much more readable and even has gained preciseness in telling me what it's actually doing. Call it a little improvement. Nonetheless, it's an improvement worth doing it. Catch that low hanging fruit when you happen to stop by to similar situations.

PS: No, I'm not going to tell you now what this little nicety has to do with monads ;-)

Im Interview: Christian Dähn

Das folgende Gespräch mit Christian ist das erste von mehreren während meiner kleinen Rundreise durch die Welt der professionellen Agilisten. Gerade bei dem heißen Thema des Agile Coaching bin ich froh, mit Christian einen kompetenten Innovationstreiber als Gesprächspartner gewonnen zu haben. Es folgt ein komprimiertes Gesprächsprotokoll. Viel Spass!

Hi Christian! Also, was machst Du eigentlich beruflich?

Christian: Tja, also: ich bin ein Agiler Coach und Trainer. Ich beschäftige mich mit agiler Einführung in Unternehmen und helfe Teams, die agile Methoden anwenden wollen. Besonders Neulingen helfe ich gut und gerne. Viele neue Dinge kann man einfach besser verstehen und umsetzen, wenn man eine hilfreiche Begleitung beiseite hat.

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

Christian: Ohh, das ist ein weites Feld. Vor nicht allzu langer Zeit war mein Verständnis der agilen Software Entwicklung, dass das primäre Ziel die Verbesserung der Produktivität im Sinne der Verbesserung des Arbeitsergebnisses ist.

Mittlerweile bin ich der festen Überzeugung, dass die primäre Zielsetzung eine verbesserte Zusammenarbeit ist. Es geht bei der agilen Software-Entwicklung um eine partizipative Unternehmung, um kooperative Teamstrukturen und eine gemeinsame, kooperative Arbeit.

Was ist Deiner Meinung nach das schönste daran, ein Agiler Coach zu sein?

Christian: Es gibt viel schönes! Eins der schönsten Dinge ist die Community und Professionalität der Gleichgesinnten. Der Austausch, der offene Umgang mit dem Lernen, das gemeinsame Mindset - all das ist entscheidend für mich und auch schön. Natürlich ist es auch die Begeisterung an den vielen Ideen und Menschen, mit denen ich tagtächlich arbeiten darf.

Wieso muss man Agilität und Agile Methoden "coachen"? Reicht es nicht, ein Buch zu lesen oder ein Zertifikat zu erwerben?

Christian: Da gibt es ziemlich viele Aspekte. Ich greife mal einen wichtigen heraus: Ein Coach ist eine unparteiische Kompetenz. Er ist gleichzeitig Experte und Unbeteiligter. Damit kann der Coach einer Situation oder Problematik einen großen Mehrwert liefern. Die äußere Sicht ist neutral, objektiv und fundiert - und das hilft bei der Reflektion sowie bei der Erkenntnis von Schwierigkeiten oder Lösungswegen.

Mit Büchern ist zwar eine theoretische Basis da - was auch gut ist - aber der Mehrwert der neutralen Perspektive kann dadurch nicht erreicht werden.

Welches ist Deiner Meinung nach eine wichtige Aufgabe des Agilen Coaches?

Christian: Hmm. Ich denke ein Spruch ist für meine Begriffe sehr treffend: "We have the answer, when we help you to phrase the question." Die richtigen Fragen zu stellen ist ein unglaublich wichtiger Faktor und Treiber.

"Richtige Fragen" zu stellen ist gar nicht so einfach. Es Bedarf einer guten Auffassungsgabe. Zuhören, beobachten, Wechselwirkungen und Kräfte erkennen, Interessen und Werte abgreifen - und dann die richtigen Fragen stellen. Die Quintessenz ist hier die wirksame Begleitung bei der eigentlichen Lösungsfindung durch den gecoachten Partner.

Wenn Du selbst einen agilen Coach beauftragen könntest, nach welchen Kriterien würdest Du denn einen agilen Coach auswählen?

Christian: Ich würde das nicht auf besondere "Eigenschaften" oder "Skills" reduzieren wollen. Vordergründig ist hier der Coach als Mensch und dessen Umgang mit anderen Menschen. Z.B: Wie beeinflusst er das Team? Steuert er mehr oder lässt er steuern?

Ich finde, die Frage ist schwer mit einem festen "Skillset" zu beantworten. Wichtig ist - wie gesagt - der Umgang und die richtige Fragestellung. Es geht sicherlich auch um weitere Faktoren wie Gruppendynamik. Genauso wie die Fragestellung, mit welchen Mitteln er Wissen rüberbringt, z.B. mit Spielen oder Workshops.

Ich denke weiterhin, dass es den Coach schlechthin nicht gibt. Es ist eine situative, individuelle Sache. Als "Tandem" muss das partnerschaftliche "Zusammenspiel" zwischen dem Coach und dem Team oder der Organisation passen. Das kann am Coach liegen, am Team, an beiden oder einfach an der Situation.

Ok, und wann gibt denn dann ein agiler Coach auf? Oder besser: Was ist selbst für den Coach "zu viel"?

Christian: Das ist sehr individuell. Sicherlich gibt es Situationen, die einen vor große, z.T. unüberbrückbare Hürden stellen.

Ein gutes Beispiel ist eine Teamsituation, bei der absolut keine Freiräume zur Entwicklung und Entfaltung gegeben werden. Gleichermaßen ist es schwer, Menschen mitzunehmen, wenn sie nicht mit einem Grundinteresse an der Sache "zuhören".

Unmöglich ist nichts. Aber: es gibt auch unpassende Momente oder Rahmenbedingungen.

Auch denke ich ist es wichtig für den Coach selbst, auch offen zu sich selbst mit den eigenen Schwierigkeiten im Coaching umzugehen. Manchmal ist es besser, einen Schritt zurückzutreten - und unter Umständen den "Stab des Coachings" weiter zu geben.

Agilität ist "In" und avanciert geradezu zum guten Ton - ja man kann sogar sagen: zum "Standard" - in der Software-Entwicklung. Welche Hürden oder Chancen siehst Du in dieser Entwicklung?

Christian: Oooh, "Standard"! Da muss ich erst mal etwas zusammenzucken.

Agilität ist für mein Verständnis kein "Standard" - und sollte es auch gar nicht sein. Der Begriff "Standard" ist für mich mit Normierung und Fixierung verbunden. Agilität hingegen lebt von der Bewegung. Gerade deswegen ist "Standard" ein schweres Wort dafür.

Es geht um das agile Manifest und die agilen Werte, die etabliert und gefestigt werden müssen. Heutzutage muss sich jedes Unternehmen, welches nicht kooperativ und vernetzt arbeitet, sich selbst die Frage der Effektivität und Zukunftssicherheit stellen.

Wie siehst Du die Zukunft der modernen Software-Entwicklung?

Christian: Ich möchte das ausweiten. Es geht meiner Meinung nach nicht nur um die Software-Entwicklung, sondern auch um die Arbeitswelt an sich. Es geht um die eigenverantwortliche, selbstorganisatorische Arbeitsgestaltung.

Das hört sich für den einen oder anderen hart und ungewöhnlich an. Und - ja - es ist ein "sich loslösen" von jetzigen Arbeitsorganisationen und Arbeitsstrukturen. Ich denke auch, dass es Teamstrukturen geben kann, die im Zuge der Globalisierung auch mit individuelleren - loseren Bindungen - existieren können.

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

Christian: Hah! Das ist und bleibt eine Entdeckungsreise. Es geht um eine genaue Betrachtung und Beobachtung der jetzigen Lage. Das Ziel ist ja nicht, Fehler zu suchen, sondern entdeckte Fehler in Vorteile umzusetzen.

Ein Stückweit liefert das agile Manifest auch diffuse Antworten. Z.B. fehlt eine klare Behandlung des Einklangs von persönlichen und kooperativen Zielen. Die wichtige Teamverwirklichung im Sinne des gemeinsamen Zieles sollte im Einklang mit der individuellen Selbstverwirklichung stehen. Da werden wir als Agilisten weiter daran arbeiten müssen.

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

Christian: Menschen, die Ihr Wirken auf Ihr eigenes Denken und Ihre eigenen Werte stützen. In gleichem Atemzug auch eine gemeinschaftliche Erkenntnis, dass ein Produkt immer aus einem Bedarf heraus entsteht - und dieser Bedarf mit Kreativität und Enthusiasmus gedeckt werden kann. Das ist sowohl eine persönliche als auch unternehmerische Komponente, die ich mir wünsche.

Vielen Dank, Christian!

Weitere Interviews der Serie "Der Agilist"

• Agile Games mit Thorsten O. Kalnin

Mein Empfinden ist vielmehr, dass es mehr denn je für die Agilität zu arbeiten und kämpfen gibt. Das mag natürlich daran liegen, dass nun viele Unternehmen sich ernsthaft mit der agilen Software-Entwicklung auseinandersetzen. Es ist mit Sicherheit auch der Fall, dass einige Software-Unternehmen wahrhaftig die Umsetzung der Agilität in Ihrer Software-Herstellung konsequent verfolgen.

Doch es gibt da noch die andere, dunkle Seite. Diese Schattenseite ist geprägt von Halbwissen und Halbwahrheiten über die Agilität. Neben der qualitativ hochwertigen Arbeit vieler Agilisten gibt es inzwischen leider viel mehr Trittbrettfahrer, die mit einem angelesenen Wissen von 2-3 Büchern gleich den Berater raushängen lassen. Mittlerweile scheint es mehr agile Berater zu geben als agile Software-Entwickler.

Darüber hinaus entwickelt sich mancherorts 'Agile', 'Scrum' und 'Kanban' zu einem halbherzig umgesetzten Methodenwerkzeug, welches nur dazu dient, an der "Mode der agilen Methodik" zu partizipieren. Da werden oftmals schlechte Berater mit schlechte Missionen beauftragt. Das Ergebnis ist - kaum verwunderlich - katastrophal. Von: "Etablieren Sie eine agile Toolchain" bis zu "Stringente Messung und Bewertung agiler Prozesse" sind alle möglichen Schandtaten für das "Unternehmen von heute" vorhanden.

Agile Sells, Why Bother?

Jetzt mögen sich vielleicht einige Leser denken: "Na und?" - Na nichts, und.

Das Agilität längst zu einer wirtschaftlichen Größe geworden ist, ist ja auch per se kein Problem. Im Übrigen bin ich weit davon entfernt, mich darüber zu beschweren. Nicht nur, weil ich selbst in der Unternehmensberatung aktiv bin, sondern vielmehr weil ich einfach der Überzeugung bin, dass die ökonomische Wertbetrachtung der agilen Methoden ganz entscheidend für deren Adaption in unsere Arbeitswelt ist.

Gleichwohl liegt es mir fern, mich hier weinerlich über die mancherorts vorzufindende ambivalente Moral- und Wertvorstellung zur Agilität zu beschweren. Nein, ich möchte mich mit der allgemeinen Situation auf eine andere, konstruktivere Art und Weise auseinandersetzen.

Besonders interessant wäre es für mich, den aktuellen Stand der 'Agilität' und dem Empfinden gegenüber den agilen Methoden abzufragen. Wenn möglich sogar aus verschiedenen Perspektiven. Eine Team- oder Unternehmensorganisation kann aus vielerlei Perspektiven betrachtet und bewertet werden. Ich denke, dass es mit dem Status der Umsetzung agiler Methoden und Werte nicht anders ist.

Quo Vadis, Agilista?

"Was also tun?" fragte ich mich. Die Antwort ist denkbar einfach: Rausgehen, in die weite Welt der Agilisten und sie befragen! Es gibt so viele Fragen zu stellen zu diesem Thema.

Fragen wie z.B. "Wie weit ist die Umsetzung der agilen Werte in den heutigen Unternehmensorganisationen?" oder "Was sind die Gefahren bei der Umsetzung agiler Methoden in der Software-Entwicklung?" oder sogar "Wohin führt uns die agile Zukunft?" Ja, all das sind Fragen, die ich mir selbst stelle - und beantworte. Doch natürlich gibt es nicht die eine einzige Antwort auf eine Frage, sondern viele verschiedene Facetten und Aspekte.

Diese Aspekte und Ansichten möchte ich durchleuchten, in dem ich bekannte, anerkannte, engagierte und erfahrene Agilisten befrage. Aus verschiedenen Blickwinkeln und unterschiedlichen Expertengebieten. Ich möchte Sie befragen zu Ihrer Meinung, Ihrer Wahrnehmung und Ihrer Position zu all den Themen, die mich als langjährigen Agilisten beschäftigen.

Der erste und wichtigste Schritt in der gemeinsamen Erkenntnisgewinnung ist die aufrichtige und offene Kommunikation. Diesem Prinzip folgend, werde ich in Interviews Agilisten befragen und das Interview dann hier auf meiner Website veröffentlichen.

Mein Ziel dabei: Neue Perspektiven und Möglichkeiten entdecken, die Agilität in der Software-Entwicklung und in unserer modernen Arbeitswelt weiter voranzutreiben. Und das wenn möglich offen, transparent und nachvollziehbar für Interessierte. Hier in meinem Blog.

Bisherige Interviews

• Agile Coaching mit Christian Dähn
• Agile Games mit Thorsten O. Kalnin

Nach einer mehrstündigen Reise hätte die Ankunft in Hamburg nicht schöner sein können. Ich habe mich sofort in Hamburg zurechtgefunden, obwohl es - man mag es kaum glauben - mein erster Besuch war. Besonders angesprochen hat mich die Gegend rund um den Hauptbahnhof. Ich konnte mich des Eindruckes nicht erwehren, dass sich die Städte München und Hamburg in der urbanen Gestaltung ihrer gleisbehafteten Reisezentren doch frappierend ähneln.

Nach der grundlegenden Orientierung und Umsetzung notwendiger Administrativa habe ich mich sehr gefreut, einen mehrstündigen Spaziergang mit Steffen durch das Stadtzentrum Hamburgs gemacht zu haben. Es ist mir immer wieder eine wahrhafte Freude mich selbst dabei zu beobachten, wie ich bei solchen Gesprächen sowohl einer fachlichen Faszination als auch einer gefühlten Minderbemitteltheit ausgesetzt werde. Ich durfte mich dabei auch glücklich schätzen, die örtlichen Spezifika über Wohn- und Bekleidungspräferenzen zu erkunden.

Ecomode und Vollgas

Es ist wohl mittlerweile kein Geheimnis mehr, dass ich ein bekennender Befürworter der hochmodernen Automobilbaukunst der Bayerischen Motoren Werke bin. Insofern greife ich hier gerne das während meines Vortrages mehrfach gewählte Bild des "Vollgas gebens" auf.

Ich habe mich auf Grund der hervorragenden Navigations- und Begleitfähigkeiten meiner Freunde Steffen und Björn zügig und pünklich am Veranstaltungsort wiedergefunden. Ein vortrefflich angemessener Gesprächsraum war für mich und die Teilnehmer ein geeigneter Rahmen, uns schnell dem Vortragsthema widmen zu können. Ein besonderes "Bonbon": Für Kaffee wurde im Vorfeld im Geiste des coffee++; gesorgt, welches als ein exemplarisches Beispiel für die bemerkenswerte Eigenschaft der Hamburgeraner dient, geistige Wachsamkeit mit kultiviertem Gesellschaftsverständnis gekonnt zu paaren.

Zu dem Vortragsinhalt möchte ich an dieser Stelle nicht viele Worte verlieren. Einzig erwähnenswert ist ein kleines Detail, welches ich sowohl während als auch nach dem Vortrag beobachten durfte. Während die gesammelte Teilnehmerschaft gebannt und interessiert meinen Ausführungen über XP zuhörte, konnte ich eine in Teilen "quite british" anmutende äußere Enthusiasmusentfaltung wahrnehmen. In gleichem Atemzug jedoch war ich sehr davon angetan, wie viele Teilnehmer meine Vortragsgestaltung mit "Ilker gibt Vollgas" kommentierten. Wieder ein deutliches Indiz für die außergewöhnliche nordische Emotionskultur, die mich bis in die fortgeschrittenen Abendstunden sehr fasziniert hat.

Ich möchte deutlich betonen, dass mein persönliches Verständnis meines Vortrages doch von dem schmeichelhaften Kompliment des "Vollgas gebens" stark abweicht. Ich habe mich selbst eher in einem "Eco-Mode" wahrgenommen. Als bewußt okönomische und okölogische Werte unterstützender Zeitgenosse ist für mich die Perspektive der Nachhaltigkeit ein besonderes Anliegen. Das gilt sowohl für meine eigene Arbeitsgestaltung wie auch für die Inhalte, die ich bei derartigen Vorträgen zu vermitteln versuche. "Auf Volltouren" war ich an diesem Abend mit Sicherheit nicht und offen gesagt möchte ich das auch gar nicht sein.

Es mag wohl auf die "bayerische Mundart" und die damit eng verbundene geradlinige, offene Kommunikationskultur zurückzuführen sein, dass sich dennoch einige Teilnehmer zu diesem für mich sehr schmeichelhaften Kommentar hinreißen liessen. Vielen Dank für die warmen und aufmunternden Worte!

Die "Hamburger Hirschgespräche"

Gleich im Anschluß an die Veranstaltung durfte ich Zeuge der außergewöhnlichen kulturellen Ausprägung meiner Gastgeber Sven und Steffen sein. In einer mir selten zuteil gewordenen Aufmerksamkeit wurde ich in ein äußerst geschmackvolles Restaurant namens "Hirsch" geführt.

Eine wahre Quelle der anspruchsvollen Gesellschaftspflege offenbarte sich mir am Tisch mit einigen Teilnehmern und meinen geschätzten Gastgebern. Das Lokal, die Karte, der Wein - doch in aller erster Linie die wertvollen Gespräche mit interessanten Persönlichkeiten verleiten mich dazu, die "Hamburger Hirschgespräche" mit der gesellschaftlichen Güte des "Karlsruher Jean-Closure" in Verbindung zu bringen.

Als einziges Makel kann hier wohl nur der (naturgegebene) mangelnde zeitliche Rahmen erwähnt werden, der es mir leider nicht zuließ, die vielen fazinierenden fachlichen und persönlichen Themen weiter zu vertiefen.

Ein Bayer im Norden

Mit einem kleinen persönlichen Fazit möchte ich diesen Bericht schließen. Ich habe während der Abreisevorbereitungen in Hamburg noch wertvolle und authentische Eindrücke von der Stadt und deren Menschen gewonnen, die ich mit Sicherheit nicht missen möchte. Der gesamte Aufenthalt in den für mich als Bayer doch gefühlt extrem nördlichen Gefilden war äußerst angenehm. Obgleich ich mit Sicherheit einige ungewohnte Situationen erleben durfte, bleibt mir der makellose positive Eindruck meines Besuches in Hamburg und der DNUG. Ich hoffe sehr, dass ich mit meinen Inhalten den einen oder anderen Teilnehmer zur weiterem nachdenken und recherchieren animieren konnte.

Den besonderen Dank der Teilnehmer sowie der Veranstalter Sven und Steffen für meinen Besuch und den kleinen Beitrag zu modernen und professionellen Software-Entwicklungs-Methoden möchte ich an dieser Stelle herzlich und innig erwidern: Sehr gerne! Nicht dafür!

Coding All Day Long

Für diejenigen, die mich schon etwas länger kennen, mag es wohl kaum eine Überraschung sein, dass ich an einem Code Retreat teilgenommen habe. Schließlich gehe ich ja auch schon seit Jahren zu Coding Dojos, allen voran natürlich das Münchener Coding Dojo.

Doch ein Code Retreat ist trotzdem etwas besonderes für mich. Einen ganzen Tag lang eine Aufgabe mehrmals mit verschieenen Programmiersprachen, verschiedenen Pairing-Partnern und verschiedenen "Rahmenbedingungen" anzugehen - das ist schon was besonderes.

Gerade der organisatorische Aufwand eines solchen "Coding Days" ist immens. Insofern bin ich sehr dankbar, dass Sebastian Benz von BMW Car IT sich der Aufgabe angenommen hat und ein wirklich hervorragendes Event ermöglicht hat. Ich habe mich den ganzen Tag über sehr wohl gefühlt und konnt mich voll und ganz auf das 'eigentliche Coding' konzentrieren. Ein gutes Catering sowie die gute Moderation rundeten das Bild ab.

Variations

Was mich beim Code Retreat besonders fasziniert hat war die Tatsache, dass eine einzige Aufgabe in mehreren "Variationen" durchgeführt wird. So war es in der ersten Session erst einmal wichtig, sich der Aufgabe selbst, nämlich Conways Game Of Life zuzuwenden. Diese erste Java-Session war ein guter Einstieg in das Format als auch in die Aufgabe.

Die zweite Session, die ich in Ruby umsetzen durfte, war ein Einstieg in TDD als Design-Werkzeug für klare objekt-orientierte Lösungen. Es war für mich insofern erfreulich, als dass ich einen sehr aufgeschlossenen und interessierten Partner hatte, der meine Vorschläge förmlich 'aufsog'.

Die dritte Session knüpfte nahtlos an die zweite an, in dem es die OO-Prinzipien genauer in den Vordergrund rückte. Man solle sich bei der Lösung besonders um SOLIDness und ein klares Objektmodell kümmern - natürlich alles per TDD. Diese dritte Session war für mich besonders interessant, weil ich das Problem in Python angehen durfte. Und das mit einem Pythonista ar Excellence. Besonders 'nerdy': Wir waren ausschliesslich auf der Konsole eines iBook G4.

Nach einer sehr ausgelassenen Mittagspause mit äußerst schmackhaften Speisen ging es frisch gestärkt an die vierte Runde, der sog. "Muted Session". Der Kniff dabei: es wird die Aufgabe in Pair Programming gelöst - ohne ein einziges Wort. Mit dem Pair Partner darf nichts geredet werden, aber natürlich weiterhin per TDD entwickelt und gelöst werden. Ein Novum für mich.

Nicht minder interessant war die Ping-Pong kombinierte TDA-Session Nummer 5, in der man die Lösung stringent nach dem "Tell Don't Ask"-Prinzip entwickeln sollte dabei und gleichzeitig das Pairing mit Ping-Pong-Testing gestaltet. Es war für mich eine sehr erfreuliche Session, denn ich konnte mit einem ehemaligen, geschätzten Kollegen in C# die Lösung vorantreiben.

Die finale Session war ein "Let it flow"-Session, in der man sich einfach in der Programmiersprache seiner Wahl ohne irgendwelche Einschränkungen oder Bedingungen der Aufgabe widmen konnte. Auch hier konnte ich wieder viel lernen, in dem ich gemeinsam mit Christine (aus der Stamm-Mannschaft des Münchener Coding Dojo) die Code Kata in Javascript angehen durfte.

Delete your Code!

Alles in Allem war die gesamte Veranstaltung für mich sehr hilf- und lehrreich. Auch wenn ich über TDD nicht viel lernen konnte, war es für mich besonders schön, mich mit so vielen Sprachen und Entwicklern intensiv einem Problem zu widmen. In gleichem Maße, wie ich jedem Entwickler und Manager ein Besuch bei einem Coding Dojo warm ans Herz lege, kann ich auch eine Teilnahme an einem Code Retreat empfehlen.

Abschließend möchte ich mich nochmals ganz herzlich bei BMW Car IT und Sebastian Benz für die Organisation, den Support, das Catering, die Moderation und die super Erfahrung bedanken.

Ich hoffe, dass es bald wieder ein Code Retreat in München geben wird, bei dem wir wieder den ganzen Tag gemeinsam neue Erkenntnisse über Programmiersprachen, Herangehensweisen, Zusammenarbeit und Testgetriebene Entwicklung sammeln können.

You might think now: Is this worth a blog-post? Even more: Is it appropriate to blog about such "news"?

There's a clear yes for me. I think it's very appropriate and important to write about it. Within the next lines, I'll lay out why I think it's so important.

Being Disappointed is not a Bad Thing

Both in my professional and personal life many people perceive the act of being disappointed as something negative. Most often, disappointment is perceived to be harmful. Just let me be very clear: It surely is not harmful. Being disappointed is a very normal, ordinary thing. The act of disappointment can be a good thing, actually.

Disappointment as an emotion is a driver to many aspects of personal and professional maturity. Nonetheless, it often is being left out in professional life. Interestingly and completely incomprehensible, it's the leaders and executives who don't seem to care about it.

A few years ago I was a lead developer / architect on a project. Some of the managers in there advised me to be cautious about my "emotions". They enjoined me to silence and "temper my emotions". Those managers surely had good intentions, yet chose inappropriate actions for their intent.

They obviously wanted to me to refocus on facts. It's absolutely understandable to strive towards a constructive and fact-oriented work. Yet, in my opinion it's not very helpful to check one's passions in order to reach objectification. It's quite the other way around.

An employee being passionate and expressing his emotions on the job is actually desirable. Most often, he's wholeheartedly committed to his tasks and objectives. He brings in his complete know-how and personality to the table. That's nothing negative. In fact, it's a very positive thing. What's important here actually is the right contact with such a passion and consequently a directed, constructive channelling of emotions.

The Art of Disappointment

I want to focus a little more on disappointment as an emotional state. Most of my friends and fellows tried to cheer me up after knowing that I'm disappointed and sad about my failure. I'm very thankful for them and I'm glad to have people around me who do care. However, I do believe that it's not only important to cheer the disenchanted up again but to go along with him through his sadness.

See, in my job I do a variety of things. Among those, I coach managers, head of's, team-leads, scrum masters, developers, testers and more. Most of those responsible and creative personalities need to deal with disappointments in daily life. Regardless being their own disappointment or those of others.

Almost all of the leadership persons I have coached so far concentrated on motivation and cheer up of the disenchanted. Even experienced managers hardly knew more than just 'bringing the comrade back to road' by motivation.

Well, that's cool, but it's only half the battle. I think that one needs to live through this stage of discourage. One needs to undergo the negative emotion of disappointment in order to negate it and leave it behind.

As for the affected person - which in this case is me - this effectively means that the emotion of disappointment needs to be faced. Ideally, one reflects all the efforts, wishes and expectations made so far. Of course, the disappointment is being lived as well with various consequences like sadness, being annoyed of all or even shedding a few tears. In this very moment, it's important to allow the emotions to happen instead of blocking or ignoring them. Yes, it's crucial to experience the emotion.

In contrast, the caretaker / minder - which in this case is ... - has a very different perspective. He first of all needs to accept that the peer has a negative emotion to carry and furthermore should prepare himself to get involved to this situation.

In the very best case, he's able to create an environment of safety and trustworthiness, so that the affected person is able to live through his emotion in a safe and intimate manner. While enabling this emotional environment, the caretaker participates in that emotion in order to be able to guide and channel the emotion towards a positive and constructive view.

Now that the emotion of disappointment is being lived and experienced consciously, a chain of concurrent activities happen: all the efforts, thoughts, actions leading to the current disappointment are being checked in mind again. This reflection is an essential catalyst to gain insights. At the same time, this recap of events are a very first step towards objectification.

Once this phase of "experienced disappointment" is being put into practice, the second step of motivation and cheer up can be seeded. I'm not going to dive into the motivation topic right now since I could write a book about it. Let's just stick with the fact that motivation and cheer up is needed as well.

It's noteworthy that the duration of disappointment depends on many parameters and is quite an individual thing. It's essential to realize that this duration is no direct indicator for the intensity or "severity" of disappointment. It just varies from person to person. Some individuals may live through disappointment very intensively and fast, others may undergo their disappointment in stages and relatively slow. It's just an individual, most often even situational dimension of the whole process of disappointment.

Speech is Silver, Silence is Scrap

Another very important aspect to disappointment is communication. Let's take myself again as an example for a disenchanted person carrying disappointment. I didn't keep my emotions for myself but told my friends about it. I told them that I've been smacked back to grounds and that I missed my goal. I told them that I'm disappointed, disenchanted and disordered. I even tweeted about it and now I'm blogging it.

The reason why I do this is essential from various perspectives. First and foremost, talking, communicating about disappointment and failure is yet another vital component to translate those negative emotions into a fact-driven objectified view. Second, it serves as an important signal for the environment. It signals 'I am having a pressing and present emotion to deal with.'

This communication is especially important in our professional life. In software engineering, you have to deal with a broad variety of personalities. Most often, different and varying emotional states come face to face. Even for team members who have been working together for years it's difficult to immediately recognize the emotional situation of the peer. Sometimes it's even close to impossible. Think of phone calls and chats.

A very professional and and constructive approach to improve such a situation is just as easy as communicating one selves emotional state concisely. Just as simple as:

"Right now I'm disappointed. I tried to achieve a professional goal, but I failed. I just wanted to let you know."

It often works miracles.

Just as a side note, you surely have noticed that the strategy of "stating your emotion" is being used in agile meetings as well. In retrospectives, the "emotional state" is being used as check-in. It's very sad that both developers and managers undervalue this very helpful approach.

Living Transparency

I want to focus on another aspect of active communication: transparency. Transparency is a great value, especially in agile working environments. Naturally, transparency does not come for free. Investing in transparency starts with your very own invest in communication. A very simple, yet powerful insight.

The sad thing is, the striking simplicity of this rule doesn't seem to help many managers and team leaders to remind and apply the rule. At least most managers I know are somewhat 'agnostic' to this fundamental law of transparency. Instead of permitting and communicating emotions, disappointment, grief, anger or anxiety, most managers dissemble their feelings. In consequence, transparency and insightful experience are being hindered.

In defense of the management guild: it's very understandable that they most often cover emotions behind curtains. The everyday business life of many managers is characterized by contracting, strategic thinking and action and very specific communication. Managers not only take responsibility but obligations as well.They are in charge of both company and employee interests, which may require them to dissimulate weakness and emotion for certain situations.

Nonetheless, it's quite sad to say that most of the managers I had the pleasure to work and go along with were trained to only do that rather than adjusting their level of communication depending on the scope of action.

Let's repeat: Transparency starts with one's very own invest in communication. Further more, it's crucial to gain and strengthen the level of trust between all team members - managers included. There's one rule of thumb, which I always give managers and team leads as food for thought:

The one who is strong enough to display weakness is equally strong to convey strength.

Despite of the fact that I mostly mentioned the manager as an example, I surely don't exclude any other role or position to care about transparency and communication. The only reason I'm overly talking about the manager in this case is that the manager has a special, added responsibility and interest to establish and foster transparency.

My Personal Disappointment

Finally, I want to get back where I started and loose a few words about my own disappointment. As already mentioned, I'm disappointed because I failed to reach a goal in my professional life. That's surely disappointing, but naturally even annoying and demotivating. It's disillusioning that something I've been fighting for truly is not happening like I wanted and wished it to be.

As most probably every professionally experienced person has been disappointed from time to time, I surely experienced a few disappointing things as well. I remember back in 2004 where I started to learn and apply agile principles & XP practices. I wasn't aware of how important a conscious experience of emotion is for me professional life. Now, being a coach for years, an experienced management consultant and agile engineer I pretty much know that the soft skill of living emotions consciously is a hard criteria for agile working environments.

My intention with this - a little lengthy - article was to encourage those who have to deal with disappointments in their professional life and somehow are stuck or don't really know how to deal with it in a positive and constructive way. It's not easy to judge yourself and face yourself consciously with the negative emotion of disappointment. Rest assured it's both desirable and helpful as long as you keep in mind your own capabilities, values and dignity.

Manch einer mag sich jetzt fragen: Ist das einen Blog-Post wert? Und vor allem, ist ein Blog-Post für so eine "Nachricht" denn angebracht?

Ich finde: Ja. Es ist meiner Meinung nach sogar sehr angebracht und wichtig, darüber zu schreiben. Warum das so ist, möchte ich im Folgenden darlegen.

Enttäuschung ist nichts Schlimmes

Sowohl in meinem persönlichen als auch in meinem beruflichen Umfeld wird Enttäuschung oft als etwas negatives, ja sogar als etwas störendes empfunden. Das ist natürlich völliger Humbug. Enttäuschung ist etwas völlig normales, alltägliches. Ja, Enttäuschung kann sogar etwas Gutes sein.

Enttäuschung als Emotion trägt zu vielen Perspektiven der persönlichen und professionellen Entwicklung bei. Nichtsdestotrotz wird es oft im Berufsleben verdrängt. Interessanter Weise oft von Führungspositionen - was völlig unverständlich ist.

So habe ich z.B. vor ein paar Jahren als Lead Developer / Architekt von manchen Führungskräften die "Mahnung" erhalten, mich emotional zu zügeln und mich "nicht hineinzusteigern". Ja, einige Führungskräfte haben damals sogar meine Arbeitsweise getadelt. Sie hatten dabei sicherlich gute Intentionen, haben aber meines Erachtens ein etwas unglückliches Mittel eingesetzt.

Denn das Argument der Faktenorientierung und die Steuerung hin zu einer sachlich-konstruktiven Arbeitsweise ist absolut nachvollziehbar. Doch Emotionen zu zügeln ist kein hilfreiches Mittel zur nachhaltigen Versachlichung. Ganz im Gegenteil.

Ein Mitarbeiter, der Emotionen zeigt und sich im Beruf auch emotional "ausdrückt", ist meist jemand, der voll und ganz bei der Sache ist. Meistens bringt er sein Know-How und seine gesamte Persönlichkeit in die Aufgabe mit ein. Das ist nichts negatives, sondern eine sehr positive Eigenschaft. Wichtig ist nur der richtige Umgang und damit die gerichtete, konstruktive Kanalisierung der Emotionen.

Enttäuscht sein will gelernt sein

Als nächstes möchte ich auf die Enttäuschung als Emotion und Zustand eingehen. Viele Freunde und Bekannte haben, als sie von meiner Trauer und Enttäuschung erfuhren, mich versucht aufzumuntern. Dafür bin ich sehr dankbar und froh. Dennoch ist es meiner Meinung nach nicht nur wichtig, den Enttäuschten wieder aufzubauen, sondern ihn in seiner Enttäuschung zu begleiten.

In meinem Beruf mache ich viele Dinge. Denken, umsetzen, entwickeln, leiten, fragen und beraten. Darunter fällt auch die Beratung von Managern, Abteilungsleitern, Scrum Mastern und Entwicklern. Viele dieser verantwortungsvollen und kreativen Persönlichkeiten müssen auch mit Enttäuschungen fertig werden. Sei es die eigene Enttäuschung oder die Enttäuschung von anderen.

Nahezu alle Führungsrollen, die ich bis dato beraten durfte, haben sich auf das "aufmuntern" und "motivieren" nach einer Enttäuschung konzentriert. Sogar erfahrenen Führungskräften im mittleren Management ist oft nichts besseres eingefallen, als die Mitarbeiter "wieder zu motivieren".

Das ist meiner Meinung nach aber nur die halbe Miete, denn Enttäuschung muss meiner Meinung nach durchlebt werden, damit man daraus Kraft schöpfen kann, um dieses negative Erlebnis zu negieren.

Für den Betroffenen - in diesem Falle also mich - heisst das, dass er sich seiner Enttäuschung stellen muss. Im Idealfall hält er all seine Anstrengungen, Wünsche und Erwartungen vor Augen und erkennt, dass es nicht gereicht hat. Er oder Sie trauert, ärgert sich, hadert oder weint sogar. In diesem Moment ist es wichtig, diese Emotion nicht zu blockieren, sondern zuzulassen - ja sie sogar regelrecht zu erleben.

Für den Betreuenden - in diesem Falle also ... - heisst das, dass er den Enttäuschten in seiner emotionalen Verfassung akzeptiert und gleichzeitig auf die negative Emotion eingeht.

Bestenfalls schafft der Betreuer durch Begleitung und Abschirmung eine Umgebung der Sicherheit, in der der Betroffene seine Emotion umsetzen kann. Dabei behält der Betreuer das durchleben der Enttäuschung im Auge und steuert durch Teilnahme an der Emotion die Kanalisierung sowie den Abbau der Emotion.

In dem die Enttäuschung durchlebt wird, werden Aufwendungen, Handlungen, Gedanken und vieles mehr innerlich auf den Prüfstand gestellt. Diese Reflektion ist für die so hochgelobte Erkenntnisgewinnung ein essentieller Katalysator. Gleichzeitig stellt es durch die Rekapitulation der Ereignisse den ersten Schritt zur Versachlichung dar, welches für die weitere persönliche und professionelle Entwicklung entscheidend ist.

Ist diese Phase der erlebten Enttäuschung erst einmal umgesetzt, kann man mit der Aufmunterung und Motivation beginnen. Ich werde auf diesen Punkt nicht näher eingehen, denn alleine der Punkt der Motivation ist schon ein dickes Buch wert.

Wie lange das "durchleben" der Enttäuschung dauert, hängt von vielen Faktoren ab und ist ziemlich individuell. Wichtig ist dabei auch die Erkenntnis, dass die Dauer einer Enttäuschung quasi keine Relation zur Intensität hat. Es gibt Menschen, die sehr schnell sehr Intensiv die Emotion durchleben - andere wiederum brauchen länger, manchmal sogar in "Schüben". Die Länge gibt keinen direkten Aufschluß über "Schweregrad" oder "Verarbeitungsfähigkeit", vielmehr ist sie ein individuelle, sogar situativ getriebene Dimension der Verarbeitung von Enttäuschung.

Reden ist Silber, Schweigen ist Schrott

Ein weiterer, aus meiner Sicht sehr wichtiger Punkt ist die Kommunikation. Ich nehme wieder mich als den Enttäuschten als exemplarisches Beispiel. Ich habe meine Enttäuschung über meine verfehlte Zielerreichung nicht für mich behalten, sondern habe es meinen Freunden gesagt, dass ich 'hart auf den Boden aufgeschlagen bin', mein Ziel nicht erreicht habe und deswegen erschüttert, irritiert und sehr enttäuscht bin. Ich habe sogar darüber getwittert und ich schreibe es jetzt in meinem Blog.

Der Grund ist wesentlich in vielerlei Hinsicht. Zum Einen ist das Reden über die Enttäuschung und die Verfehlung ein weiterer Vektor in der Verarbeitungsgeometrie, der von der reinen Emotionsdarstellung zur faktenbasierten Sachdarstellung führt. Andererseits ist es auch ein wichtiges Signal an die Umgebung und alle Beteiligten, dass dieser Zustand akut und präsent vorhanden ist.

Gerade im Arbeitsleben ist das ein essentieller Faktor. Man trifft unvermittelt auf viele verschiedene Persönlichkeiten, die oftmals unterschiedlich emotional angeregt sind. Obgleich man z.T. jahrelang zusammen arbeitet, kann man meistens nicht auf den ersten Blick den Gemütszustand des Gegenübers einordnen. Manchmal ist das sogar unmöglich - man denke an die berühmte Telefonkonferenz oder den Chat mit Offshore-Kollegen.

Eine persönlich und professionell gute Herangehensweise zur Verbesserung solcher Situationen ist ganz einfach das kurze und präzise mitteilen des eigenen Zustandes. Ein klares und deutliches

"Ich will Dir kurz vorab sagen: Ich bin momentan sehr enttäuscht. Ich habe ein Ziel nicht erreicht, welches ich mir gesetzt hatte."

wirkt geradezu Wunder.

Im Übrigen ist die Mitteilung des Gemütszustandes bei agilen Meetings wie z.B. der Retrospektive ein gängiges und sehr wirksames Mittel und wird oft beim sog. "Check-In" in die Diskussion angewendet. Leider wird es meist von Entwicklern und Managern oft zu sehr auf die leichte Schulter genommen - oder sogar belächelt.

Transparent leben und arbeiten

Eine weitere nicht zu vernachlässigende Eigenschaft der aktiven Kommunikation ist die Transparenz. Transparenz ist ganz besonders im agilen Umfeld ein hohes Gut, welches gehegt und gepflegt werden will. Eine einfache, aber wichtige Erkenntnis dabei ist, dass Transparenz immer bei einem selbst beginnt. Anders gesagt: nur wer sich selbst den anderen öffnet, ermutigt auch andere, sich zu einem zu öffnen.

Diese geradezu frappierend einfache Regel wird meiner Erfahrung nach sehr oft von Führungskräften wie z.B. Teamleitern oder Abteilungsleitern vernachlässigt. Anstatt sich zu öffnen und z.B. Emotionen wie Enttäuschung, Niederlage oder Aufregung zu kommunizieren, verstellen sich viele und verhindern damit Transparenz und Erkenntnisgewinnung gleichermaßen.

Einerseits ist das natürlich sehr gut nachvollziehbar. Das Alltagsleben von Managern ist oft geprägt von Verhandlungen, von strategischem Handeln und von gezielter Kommunikation. Darüber hinaus sind Manager nicht nur einer Verantwortung, sondern implizit auch einer Verpflichtung gegenüber dem Unternehmen und Ihrem Wirkungsbereich ausgesetzt. Es ist in einem solchen Umfeld oft nachvollziehbar und manchmal sogar notwendig, keine Schwächen oder Angriffspunkte zuzulassen.

Schade ist jedoch, dass ein Großteil der Manager, die ich bis heute beraten durfte, eben nur diese eine Perspektive umgesetzt haben, anstatt Ihre Kommunikation auch an den gegebenen Handlungsrahmen zu justieren.

Nochmal: Transparenz fängt mit der eigenen Kommunikation an. Darüber hinaus ist es für eine agile Führungskraft essentiell, das Vertrauensverhältnis zum eigenen Team zu stärken. Ein Faktor ist dabei die Transparenz und Kommunikation. Eine einfache Merkregel, die ich faktisch jedem Manager als Denkanstoß mitgebe:

Wer stark genug ist, Schwäche zu zeigen, ist auch stark genug, Stärke zu vermitteln.

Obwohl ich gerade sehr oft den Manager als Beispiel zitiert habe, schließe ich damit Entwickler, Tester und andere Teammitglieder nicht aus. Die 'Konzentration' auf den Manager ist nur der Tatsache geschuldet, dass gerade diese Position sich mit dem Thema der Förderung von Transparenz stark auseinandersetzen sollte.

Meine Enttäuschung

Zum Abschluß möchte ich noch ein wenig auf meine Wenigkeit und meine derzeitige Enttäuschung eingehen. Wie Eingangs schon erwähnt bin ich enttäuscht, weil ich unlängst ein berufliches Ziel nicht erreichen konnte. Das ist nicht nur enttäuschend, sondern natürlich auch ärgerlich und demotivierend. Die Tatsache des Scheiterns an einer Sache, die man mit allem Willen und Kraft erreichen wollte ist ernüchternd.

Ich habe - wie jeder andere berufserfahrene Mensch auch - schon einige berufliche Enttäuschungen hinter mir. Manche weniger schlimm, manche mehr. Als ich 2004 mit XP-Praktiken begann und mich mit Agilität auseinandersetzte wußte ich noch nicht, wie wichtig die bewußte Verarbeitung von Enttäuschungen mir noch werden würde. Erst als ich mich mit den Aufgaben des agilen Coaches und der professionellen Management-Beratung auseinandergesetzt habe, wurde mir selbst klar, dass dieser weiche Faktor ein hartes Kriterium für Agilität ist.

Ich möchte durch diesen Blog-Artikel und die Transparenz alle diejenigen ermutigen, die sich vor den Kopf gestoßen fühlen, wenn sie berufliche Enttäuschungen durchleben oder sogar begleiten müssen. Es ist kein leichter Schritt, sich selbst einzuschätzen und sich selbst bewusst einer negativen Emotion wie der Enttäuschung zu stellen. Aber es ist ein lohnenswerter Schritt, wenn man seine eigene Würde, seine eigenen Fähigkeiten und seine eigenen Werte im Auge behält.

Multimate Maniac

You surely already have realized that there's no mutual exclusiveness for progressive and excessive schools. However, in practice I often find myself in a debate between both. That's primary reasoned in the fact that practitioners of both strategies tend to go overboard with it.

The progressive language learners mostly pick a language or two and learn them for a given timebox, most often a year or so. They try to dive into the language concepts very fasts and practice their newly gained knowledge with pet projects, such as writing blog applications or other relatively small scaled software.

The excessive language learners usually do some up-front evaluation of languages and paradigms for a certain time, ranging from a couple of weeks up to years. After having made up their mind, they explicitly choose one language and stick with that language for years. Their goal clearly is to fully utilize the language as well as the ecosystem surrounding it.

Being Progcessive

I'm personally able to relate to both approaches. Nonetheless, I feel myself more comfortable with the progressive approach. I'm a firm believer of diversity and short feedback cycles. Hence, I like to pick a language and dive into it for a while (usually a couple of months). If I'm interested and find myself learning new perspectives - or if the language enables me to raise my productivity in some cases - I usually opt to stick with that language for a year or more.

The great benefit I was experiencing in learning new languages certainly was to find new perspectives. Like different approaches to common solutions because the language supports different features. Like different program design because different idioms of modularity, objects and data structure design exist.

In past years, I delved into ActionScript, PL/SQL, JavaScript, PHP, C#, C, Perl, BASIC, Java, Processing and Ruby. This year I'll dig into Python and F#. However, there's only a few where I safely would categorize my knowledge as profound, namely JavaScript and C#. That's mainly because I was very excited about both languages in the beginning and the middle of the last decade (C# ~2003, Javascript ~2006). This mixed approach might well be entitled progcessive.

(BTW: I know, I'm not good at creating new words, but I wanted to give myself a try. That's why I'm rather a computing linguist than a natural linguist ;-)).

One Language Rules All

Apart from all those programming languages in the field and the rise of language-orientation, I finally want to make a (personal) point on being a "polyglot programmer". I believe that it's a good thing for both your "resident" language skills and the languages you might explore and visit to be curious. Being a polyglot programmer not only broadens your "programming speech", but enables you to reason better about your engineering tasks.

Even for non-developers like testers, business analysts, scrum masters, product owners and managers, I strongly recommend them to learn a new programming language from time to time. Not necessarily the language they might be in contact with through development colleagues. Just the language they happen to find interesting or useful for their particular needs.

However, from the past years of professional experience I had as developer, team lead, architect, scrum master and manager, I came to the conclusion a few years ago that there's one single language (plus dialects) every professional in modern software engineering must learn.

Yes, right. Every Pro in Software Development has to learn this essential language, which effectively is the language to rule them all: the customer language.

WYSIWYT: What You Say Is What You Think

If you want to succeed in creating software, the customer language is indispensible. This perspective has been in software development since the very first beginning. It started out with requirements encompassed with a glossary, it continued on with use cases and scenarios, up to user stories and feature fares.

Even in a very technical sense, the customer language was always in focus. It started with business routines and business modules, was superceded then with the object-oriented domain model and there even has been improved with various principles such as the ubiquituous language from DDD.

The goal of all those principles and methods is simple: understand your customer. or user. or both. (Yes, there's a difference between customer and user, but I won't dig into that now). The thing is: if you want to understand your customer, you need to listen to your customer. But listening ist not all. You need to comprehend what you're listening to, you need to ask questions to what you're listening to, you even need to refine and improve to what you're listening to.

Language and Translation

Admittedly, it's not easy, often impossible, to learn the complete customer language and the underlying concepts and semantics of the domain in question. However, you don't need to be a domain expert or customer whisperer to understand your customer. The key thing here is to constantly care about the communication between you and your customer.

That being said, the're so many techniques and methods who can help you to understand your customer and let him understand you. As a longterm XP practitioner, the customer test specifications always were in customer language stripped down to keywords and actions. This has evolved to a number of key practices to learn the language of your customer:

• Behavior-Driven-Development
• Test-Driven-Development
• Specification By Example

Honestly, learn at least one of the practices mentioned above and I guarantee you: you will understand your customer better than before. Even better, learn all of them and you will understand your customer as never ever before. Now, if there's really only one single thing you absolutely need to know in the field, then you'd better choose learn and practice the Gherkin language.

Be a polyglot. Learn new languages, new perspectives and new paradigms. Yet, first and foremost, learn the language of your customer and be sure to regularly practice it.

Ok, the manifesto is well-known. But how about the Agile Principles? Are they known as broad as the manifesto is? I personally doubt that. Hence, it's worth to have a few words about the principles, their role and how they relate to the manifesto at all.

Values Need Actions

First of all, the principles are very tightly bound to the manifesto itself. While the manifesto communicates agile values, the principles communicates the means of actions (practices) to embrace the values of the manifesto.

Surprisingly, most people I've met in my career think that the principles were some "added sugar" to the manifesto, probably even have been added at a later stage. As far as I know, this was not the case. I've always had the principles present with the manifesto itself. Albeit the manifesto surely is being referenced a lot more.

All batteries included

The last few days I had a couple of discussions with colleagues, friends and other "agilists" around me. The topic was about engineering (programming) niveau. More precisely, it was about the culture of caring about your work and skills.

In almost all of those conversations, I was referring to the Agile Principles, especially one particular:

Continuous attention to technical excellence and good design enhances agility.

This principle puts a clear message: Skills Matter.

Excellent!

For me this principle is a clear indication that a skilled, continuously learning and passionate working person is required to make agility a success in a project or product engineering context. It clearly alerts us to maintain and extend our very core asset of skill, which in effect is the manifestation of capability through knowledge and experience.

The great Martin Fowler wrote about this principles a decade ago in an Article on SE Magazine:

When many people look at agile development, they see reminders of the "quick and dirty" RAD (Rapid Application Development) efforts of the last decade. But, while agile development is similar to RAD in terms of speed and flexibility, there's a big difference when it comes to technical cleanliness. Agile approaches emphasize quality of design, because design quality is essential to maintaining agility.

Obviously, quality in design is easier achieved through technical cleanliness. Technical cleanliness is easier achieved with a steady motion to improve your technical capabilities and excellence.

Is "Skilfulness" Agile?

There's one very important question being around in agile practitioners mind for years now: Does skill relate to the Agile Manifesto? Or rephrased: Is skilfulness agile?

Even the creators of the manifesto where rethinking this aspect over and over within the last years. I remember very well the thought-provoking article on dark spots of the manifesto form the great Brian Marick. Among other values he explicitly mentioned that Skill as a Value has been left out in Agile Manifesto.

I do agree with Brian in a sense that the requirement of skilfulness is being far undervalued in the whole agile universe. I'm a firm believer in continuous learning and improvement, especially when it comes to my very own capabilities and know-how.

Craftsmen Capability Care

You may recall now that this is essentially the same song played by the wonderful Uncle Bob as well for years now. A few years ago he was that much fed up with the underestimation of engineering skills in everyday agile projects that he draw a line and crafted the Software Craftsmanship Manifesto.

It basically alerts us to take care and responsibility for what we do. It reminds us to craft software with honor and pride. It pushes us to strive for the best possible result. It just raises the bar.

That's what I'm doing in my job and life as well. Naturally, I signed the manifesto and I'm living and promoting these values whenever I can.

Uninterested Unwilling Underachievers

Consequently, it's obvious to me, that skill is essential in agile engineering. Agreed, it's essential anyway, not only limited to agile software development. Yet, for agile engineering, it's even more a crucial factor to success. Being on an agile project requires you to constantly choose the path of improvement for your own skills.

That being said, it's literally unacceptable for me to tolerate individuals or opinions in agile projects, who are uninspired and uninterested in what they do and what the team does. In my whole professional life, I always tried to help people to get over that. However, if they're not interested in being professional and caring like a professional and acting like a professional - then they should better get out of the way and let the professionals do their job.

Being uninterested in ones own skills, in ones own work and in ones own perspective to creation is surely a sad thing. Whenever you happen to meet such individuals, please treat them like adults and take them for serious first. Talk with them, try to help them, try to engage them.

If all that doesn't help, there's nothing more left than concentrating your efforts for other things or individuals and leave the underachievers behind you. This is a very important thing to help yourself in being constantly motivated for your continuous effort to improvement in a sustainable, well-balanced pace.

There's no Pill for Skill

Finally, I want you to remind that nobody says that your job is going to be easy. Nobody says you'll earn money by fooling around. Nobody says that you'll spend your life in kinder garden only. Keep in mind: your value is your values.

There's no Pill for Skill. Stand up, get up. Fight for your values, learn for your skills, accept your challenges. STFU! Get Up!

A tool is just a tool

Everybody probably knows it already, but I wanted to re-iterate that: A Tool is just a tool. Tools are very important these days for software development. Literally every developer needs his own set of tools. Plus, in professional software development, tools are an indispensable means to get things done.

As for the developer perspective, it's the IDE, the editor, the shell, the issuetracker, the CI-engine, the VCS and many more software making up the "tool chain". However, even hardware can be counted a tool: It seems to be a big difference these days to use a MBP, a notebook, a desktop or even an IPad as primary development system.

Give me the tool, you fool

Lately, I got the impression that tools not only are important to us, but have become more important than they actually should be. Whenever a developer sets up a new box around me, he's asking questions like

• what editor are you using?
• what shell is coolest?
• what plugins are shiny?
• what is hip, my hipster hippies?

On one hand, I understand that it's important to look out for improvements and make some research on it. On the other hand, I don't get it why those questions are being asked.

Even more, I don't get that tool X and tool Y is being used "just because it gives you good geeky karma." What's that for an argument? Are you serious? Are you a developer cranking out some code or just a barbie doll looking out for fashion shoes? I don't get it.

Tools to the rescue

I think it's a very good thing to look around what's happening and evaluate new methods and tools. Nonetheless, I personally prefer to actually use a tool only if I obviously need a tool and then value that tool and eventually compare that tool with others in the field. For a few developers around me, I have the impression that the tool chain is just being chosen because it's kind of hip and geeky.

Take Resharper, VS Power Tools, Zsh, VIM, ST2, MBP, WebSharper, c9.io and whatever freaky tools might exist in this universe as an example. I personally use VIM for around 2 years now. I'm not even at 10% of what is possible with VIM. And this was and is a great lesson for me. Both positive and negative.

On the other hand, I can't (and don't want) to miss Visual Studio and Resharper when it comes to serious .NET development. That's cool and fine for me. I love those tools (for specific tasks). However, I wouldn't ever touch a CSS or HTML file with VS. YMMV.

Tool me under!

I'd like to encourage developers to first use what they have and look around if existing tools can help to improve, automate or simplify the task they're actually need to get done. Once you see that your tool-chain limits you or leads you to inefficiency, the motivation for new tool evaluation is very well satisfied, Imho.

Don't just follow the white rabbit and cry out to be equipped like a transformer just to edit a simple README file.

Every working environment, literally every project has a different culture. Yet, there are similarities throughout projects. A few reasons for those similarities are similar technologies, similar tools and similar mindsets. That's true for the .NET-related projects as well.

I want you to notice once more that I'm neither leaving nor staying with the .NET technologies. I have perfectly valid reasons to use .NET, Mono, and FSharp, and I surely will use these cool .NET technologies. However, I have good reasons to criticize some other aspects of the .NET ecosystems as well.

Although I mentioned it in yesterdays Top 5 reasons for using .NET post, I want to emphasize once more, that the key to successful software engineering and successful software products is not the technology being used but the people being involved. Enough introduction.

Top 5 reasons to leave .NET

Here's my top 5 reasons why I look forward to look for alternative technologies.

Nr. 5: Microsoft

Yes, you read correctly. Microsoft has made it into my top five why I not like using .NET. The reason is dead simple. For many years, Microsoft left me as .NET developer think that .NET is the "new VB", the new shiny 4GL platform where everything works with click & run. Moreover, instead of advocating serious engineering, Microsoft just wanted to sell .NET and the new VS versions as RAD engineering tools. They actively made me as the seriously engaged .NET developer think that I'm at one level with VBA Macros and SQLWindows.

Second, the way Microsoft is supporting the .NET community is not focused on engineering, but focused on sales and marketing. That's the impression I got from many years of active .NET community participation. I'm still a CLIP Member, by the way. To me, Microsoft prefers shows their appreciation to people that promote and sell their products instead of showing appreciation people that utilize and improve their products.

This makes many .NET communities needlessly to be a sublte product and people marketing platform rather than a community of users and innovators.

I like to meet with developers, not with self-proclaimed heros or sales masters.

Nr. 4: Homogenous Harmony

This topic is related to Micrsoft, but is not limited to Microsoft in .NET ecospace. It's about what I call the fallacy of "homogenous harmony". In professional .NET world, vendors try to lock you in with their products. You want a widget library? Take X. It plays very well with search library of vendor X, but not of vendor Y or vendor Z. This "Lock In, Feel Free"-Game is played over and over again, no matter what developer tool or library it is. Nearly all .NET vendors invest more in not supporting other vendor's tools than in investing to coexist with them.

This not only is depressing for the developer or a risk from strategic software product management point of view. No, the biggest negative impact is the active and effective lowering of innovation. This "unique partnership" strategy for developer tools leads to laziness and blindness for options.

Developers just stick with that lock-in because they know that they have no other option. That's the point where the developer as individual as well as the company is loosing innovation.

I prefer diversity over monotony.

Nr. 3: Developer Productivity Tools

Guess what, it goes on with the tool chain. I'll start with TFS. Just to get it out of my way. TFS is the perfect example for a contradicting product. While it claims to be a "Developer Productivity Tool", it's straight forward just the opposite of that. It merely embraces process guidances, guidelines and protectivism, that's it. Period.

The same is true for other products in .NET Devland. I'll pick the beloved Visual Studio as an example. The concept of all the fancy XML-, Resource-, Database-, Publish-, Webform-, HTML- and XYZ-Designers Visual Studio has is just to do one single thing: Hide complexity. Yes, you read correctly, complexity. You know what that means?

That means that you as Visual Studio "Developer" don't even get to know what you are doing. In the end, a developer doesn't need to be a developer anymore. It's just doing it because there's the menu option to do it. It's doing it because Intellisense says it's possible. It's doing it because there's a wizard guiding to "Finish Unit Tests".

This effectively means that your gained productivity is sold for being treated like a dumb user who is trying to get a paragraph formatting fixed in Word, instead of being treated as an engineer who is responsible of actually knowing what the hell he is doing with all those bits and files he's juggling with.

I want to be taken for serious and not as dumb click-dummy.

Nr. 2: Optimization Over Innovation

First I thought this would be my number one, since the preceding arguments touch the fact (or lack, respectively) of innovation as well. In more than half of all my .NET projects, I perceived to live and deal with a culture where optimization is favored over innovation.

To me, this is one of the biggest Anti-Patterns of agile and modern software engineering. Hence, It's quite sad for me to realize that I happened to experience such a culture often. Interestingly, very often with .NET projects (of different sizes!).

I think that most .NET-related projects are profit-oriented with the notion that everything what is related to software engineering is valued as a cost rather than an investment. In consequence, budget plans are being made, resources are planned upon tasks and money is correlated with time instead of feature.

You might argue that this is just a characterization of enterprise projects and has very little to do with the technology being used. Very plausibe argument, indeed. Nonetheless it doesn't reflect my experiences.

For instance, I've had (very) large, enterprise-scale projects in PHP and C. For both of the projects, I've had plans and goals to achieve. However, in both projects I always had the chance to innovate prior to optimize. All my innovation efforts have been taken for serious, then evaluated and mostly adapted.

On quite a number of my .NET projects, the contrary was the case. People were awarded when they could reduce cost and they were punished when they could expand market and turnover.

I prefer innovation over optimization (while I do optimize as well).

Nr. 1: No Invest To Interest

Yes, my number one reason for preferring other technologies over .NET is the lack of "invest to interest". As much as I am technology-agnostic, I haven't seen so many developers not being interested in their job as I did in a large number of .NET projects I made. What a sad sentence this is. Yet, it perfectly describes my experiences so far.

I've had one - yes, one single - .NET project so far where I had the genuine impression that every developer involved in that project was interested in what they actually are doing. (Note: For the curious mind: parts of this project were codenamed after cuban cities.)

Even more, some of the uninspired developers were even advocated by project managers and Scrum Masters as "experienced, low-key and thoughtful" people. Just because they didn't do anything.

I'm well aware that this problem is not limited to .NET projects. There's tons of projects in other languages where the same is true. Yet, I happen to had the experience that especially within .NET projects the number of uninteresed, unwilling, unimpressed and unimproved "software developers" is exceptionally large compared to those few developers who actually take their job and assignment for serious. I'm quite glad to say that in my current projects the majority of developers actually do care.

The latter mentioned mostly are brave and very strong minded people. They mostly continue in a restless manner to improve whatever they can. It's a very sad fact that mostly those few are being looked at as "disruptive elements" and troublemakers.

This lack of "invest to interest", again, is one of the biggest Anti-Patterns of modern software engineering. It inherently leads to a protective, non-progressive and disrespective working environment in which it is very hard to achieve any valuable result.

I prefer to work the best I possibly can instead of working just as much as is necessary.

Criticism and Correlation

As I already mentioned before, I'm well aware that most of the above arguments are not specific to .NET itself. It's a valid criticism of mine to argue that there's no concrete correlation between .NET as technology and the very "non-technology-related" statements I made. I do as well recognize .NET usage in indie game studios, movie and animation agencies and whatever 'cool' and 'hipster' startups and working environments there might be.

Nonetheless, this list reflects my experiences I had so far on the majority of my .NET projects. I mostly gained the impression that the delusive culture of "professional engineering" in .NET ecospace is being aided and supported by the technology and the companies around that technology. This especially was the case where .NET and other .NET related products like TFS, various OR/M or Win/Webform-Libraries are being used to follow the "spirit of RAD".

On the other side, I had the chance to work on PHP, C, Java and JavaScript projects as well. For the vast majority of those non-.NET projects, I had a very different experience regarding the abovementioned perspectives. Especially my Nr. 1, 2 and 3 arguments were not as apparent and present as on almost all .NET projects I had so far.

That all being said, I still have great respect for all .NET enthusiasts and community members. In fact, I even do admire a few of them for their professionalism, for their passion and for their brave and powerful way of promoting the positive things of .NET as a technology as well as of the .NET community itself.

Moreover, I not only had a "perfect" .NET Project but also had a few .NET Projects where I met very smart people, learned a lot of things and had a great time building cool products with cool .NET technologies. I enjoyed .NET development very much and keep enjoying it.

Alternatives and Advantages

I'm not sure whether any other comparably large and affecting technology would have significant advantages over .NET in the abovementioned points. Lately, I've been around the Java and Ruby communities and both are very different from eachother as well as different to the .NET community.

Last year I learned Ruby. Not inside out, but fairly well. It was a great experience. Both from technical as well as from personal perspective. This year, I'll most likely dig into Python, their related technologies and their communities. I'll learn FSharp, a .NET-related language, as well.

The message I want give to you, my dear reader, can be summarized quite easily: Take the chance and look beyond your known area. It surely will be of advantage for you. If you are a rubyist, look how the .NET way of events and UI binding works. If you are a .NET guy, look what advantages you can take away by experiencing how Rubyists deal with database migrations and testing. Either way, you can turn alternatives to advantages. And that's what I'll look after as well.

Turn alternatives to advantages.

While I perfectly understand some arguments of the abovementioned, I do have a slightly different view on this whole topic of technology switching. I personally believe that success is not a matter of technology but a matter of people. Whatever shiny Ruby, Node.js, Scala, C, Linux, OSX, iOS, Python, Android, PHP, WinRT, NaCl technology you're using. It doesn't matter. You can do crap and bullshit as well as shiny cheesy nifty things with any Technology.

Having this in mind, I want you to know that I'm pretty much a technology-agnostic person. I get my stuff done. With Linux, with Windows, with .NET, with Ruby - and even with things like paper and pencil.

I think many people leaving the .NET ecospace made very valid points. I respect them for their decision and I'm pretty sure they will do great stuff with other new technologies as well as they did with technologies they were using before. Yet, I lately got the impression that the topic was burdened a little with a "negative karma". There might well have been destructive arguments or at least a notion of disrespectful, angry, harsh way of saying things.

This blog post is to add another, yet surely incomplete perspective on the .NET technology and the community surrounding it. It's just about to signal a simple message: "Let's think positive and look at eachother with respect". That's it.

Having said so much in front of a simple listing, I think it's time to finally introduce you the list I'm talking about all the time. I made my mind about what I personally think is cool about the .NET technology. Surprisingly, I got many things I pretty much like about the .NET ecospace. I sorted them by "level of importance" (to me), picked the top five and just wrote a couple of words for my reasoning. So, here it is.

Top 5 reasons to stick with .NET

Here are my top 5 reasons why using and working with .NET is fairly cool.

Nr. 5: Microsoft

Yes, you read correctly. Microsoft has made it into my top five why I like using .NET. The reason is dead simple. Microsoft "invented" it. Apart from Microsoft being bad at many other things, Microsoft did plenty of things right as well. One thing, obviously, is the .NET Framework itsef. The complete CLI, CLR, CTS and CIL make up an awesome managed execution environment with great capabilities.

However, it's not only the simple credit to creator here. Microsoft continued to develop and support the ecosystem with the DLR, with research, new languages and supplementary products. In the last years, Microsoft even opened itself a little more towards the OSS community and got more open minded.

Yes, there's a lot of things what Microsoft may have done far better. Yes, there's some things what Microsoft should not have done at all. But, there's as well a few things Microsoft did get right. And there's a couple of things where Microsoft did an awesome job.

Nr. 4: Diversity & Variety

Again, this might not be a very obvious argument at first place. Nonetheless, I find the .NET ecosystem to be surprisingly diverse. You meet a lot of different people with different mindsets, different skills and different areas of interest. From enterprise developers doing BI-SQL-Server stuff, web developers going crazy with ASP.NET MVC, desktop application developers up to game devs using XNA. A broad set of usages makes .NET attractive to me as well.

Second, it's not only the variety of usage, but the variety of people and cultures working with the technology. The fact, that in .NET Community a web nerd regularly meets up with the enterprise guy alongside with the powershell sysop is quite nice actually. Especially when you consider that the community sticks together and manages to handle and leverage this diversity.

Nr. 3: C# (CSharp)

This one is obvious. From my top three ranking, the CSharp language is on bronze. C# is big step. As a language itself, as well as when it comes to .NET development. C# makes OO-design and OO-development much more comforatable than with many other languages. C# is a leading edge multi-paradigm programming language.

One honorable, very high value of C# is the progress and development of the language itself. From version to version, C# got features which most of the time not only made sense, but were evolutionary as well. Generics, Linq, Lambda, Extension Methods, Dynamic and soon Async/Await. Comparing with other languages in the field, the C# lifeline reads pretty cool. And guess what: It's even pretty cool to use all those features.

Nr. 2: F# (FSharp)

Ranking on second is FSharp. Yes, FSharp. FSharp is an awesome language. I'm very thankful that Microsoft Research did such a cool job and managed to develop a language favoring the functional programming paradigm. Combined with the big and diverse .NET Framework, FSharp not only is the new kid of the block here. FSharp is a shift in how functional languages will be used in everyday computing.

I'm quite new to the FSharp game. Yet, I'm fascinated and thrilled of it. It makes me rethink on how to solve problems as well as see, how cool it can be to embed a functional language into the .NET ecosystem. FSharp will most likely change every aspect of the framework for the better. Although I haven't learned the language to its full extent yet, I'm quite sure that C# and F# will be equal partners when it comes to develop great software.

It might well be, that once I learned F#, I'll want to learn other functional languages or styles as well. I might well be, that I might stick with C# or other imperative languages as well. It might well be, that I use both and enjoy both. Let's see.

Nr. 1: Mono

The winner and the number one reason why working with .NET is cool, is: Mono.

I can't express in a few sentences what great gift Mono is for the .NET community, the .NET development and the .NET future. Mono made many things possible we all wouldn't thought could be possible. Mono contributed solutions and products we all are using on a daily basis. Even more, Mono is even ahead of Microsoft in particular areas, such as CAAS or device targeting. Mono made Cecil, MonoTouch, MonoDroid and many other cool things like Unity possible.

I'm working with Mono since around two years now. At the beginning of the last year, I decided to completely switch my personal .NET development to Mono. I even had a commercial project with Mono. During this time, I learned a lot about the .NET Framework, the class libraries, the Mono compiler and the "Monoid" way of software development. I'm very thankful for all what I have learned so far and I'm looking forward to learn more and contribute to the Mono and OSS comunity.

Please, .NET developers, contribute to Mono. Please, .NET community, use and enhance Mono. Please, Mono, continue to be so awesome.

This time I'm going to share another technique which I found to be very helpful in brownfield engineering scenarios. Obviously, I named this technique "Test Implants". Test Implants are no solution to "untestable" code, but help you to find out the parts which need to be addressed.

Effectively, every test implant I wrote made me rethink on how the code might be restructured to fit all requirements. For me, test implants are a simple, feasible way to get interaction tested without essentially restructuring the organization of the code. I personally use test implants for over a year now and found it very useful most of the time.

I'm going to show you test implants using a little fictional story. No intentions behind that, the story is just a cake with topping alongside the coffee. The title of the story, obviously, is "The Quest Of The Test". Enough introduction, let's just start.

I'm going to tell a little story about legacy code, bugs and testability. You, my dear reader, will be put right into the fabulous adventure of finding out what a test implant is. Enjoy.

A typical Brownie

It's a regular, rainy Thursday morning, five past nine. As always, you're a little late to work. You quickly pull of your coat while switching on your monitor and logging in with your left hand. It's not that your password isn't complex. It is fairly complex. It's the virtuosity of your memorized typing of course that makes it possible to login single-handed.

Once you're seated, you see bad news in your inbox. "Bug in Chronograph!" says the title of the mail. What? The chronograph? The legacy code you just have become the official maintainer for?

Justice has left this town. That's for sure.

Ok. Ok, ok. While you concentrate to breathe in regular intervals again, your brain starts to send plausible signals: "Get me a coffee. Then we'll fix this bitcrap, buddy". Aight! You put in a Nespresso "Volluto" for starters and hit the button. While the coffee machine is at your command, you open the Chronograph files. You happen to recall that it's using TimeServer, an almighty third-party DLL. It contains classes and methods to fetch a global standard time from internet and translate it to local time.

Bing! Coffee done! "A morning with bugs and coffee. The usual suspects in my ordinary life." is the most original thing what you are able to tweet right now about your adventure. Ok. Social shit done as well. Start working. Now.

Sources refreshed, project opened in Visual Studio, table light dimmed. You're just rereading the code of Chronograph, which has been written in "ancient times". Obviously without any unit tests at all:

public class Chronograph {
  private CultureInfo _culture = CultureInfo.InvariantCulture;

  public bool IsDirty { get; set; }

  public LocalTime SyncWith(TimeServer ts) {
    var localTime = new LocalTime();

    if (IsDirty) {
      TimeEntry te = ts.GetTime();
      te.Apply(_culture);
      localTime = te.ToLocalTime();
    } else {
      TimeEntry te = new TimeEntry(localTime);
      te.Apply(_culture);
      localTime = te.ToLocalTime();
    }

    return localTime;
  }
}

Hmm. This code smells to have bugs. You're staring at it and think "Oh my. Look at the dupes. Rookies." If you wouldn't just slurp your coffee while browsing code, your left hand would be ready to serve a generous face-palm. Your excellent nose didn't mislead you, as you soon realize while reading the bug report in Bugzilla:

Bug Nr      : 0815
Title       : culture is not updated when clock is in sync with server
Component   : Time Sychronizer (Chronograph)
Description : While the local time is in sync with server, the culture needs to be "updated" regularly. It happens not to be the case. The time server API has a specific function to update a time entry with culture: TimeEntry.Ensure(CultureInfo). Use this function to keep culture up to date.

Good to know that a professional like you is taking care of this nifty bug. While browsing through TimeServer API, you realize that TimeServer, TimeEntry and LocalTime classes are all sealed. Without interfaces.

Your mouse pointer moves the scrollbar slow. Very slow. You try to cheer up yourself: "An API style I've seen a hundred times at least. Nothing shocking so far." You know the truth is different. You wished to stay at home today. Now you're here. Right in front of this artfully crafted code. Not.

Riiing! 10 AM! Stand-up time! "Come on, McFly, wake up!" is the flash of thought right after the alarm window popped up on your screen. Lock the box, put off the mug, off to 3rd floor! Since your department has moved last year from 3rd to 1st floor, these dailies happen to have the notion of helping the staff to burn calories. You hurry up to entrance. "Yeah. Right." - all elevators blocked. Stairs, as always.

TDD is En Vogue

Arrived at 3rd floor you see all devs listening to the lead developer. You don't like him, yeah. Nonetheless, this time it's as if an important announcement is about to happen. "Will he retire?" is all what you can imagine to be a positive thing right now. However, surprise is ahead.

From now on, the management and the entire organization will support and encourage to develop literally everything with TDD. No code will be put in production which is not TDD'd, no bug will be resolved without proper tests using test-first method. Period.

It's Christmas and Eastern altogether. Did he really say TDD? Yes, he did! Life is a roller-coaster. After having reached the grounds this morning, you're now back on track. Finally TDD. All those arguments you had in kitchen, all those emails you wrote to colleagues with links to Uncle Bob and Kent Beck, all those code reviews and little wars about test frameworks and CI integration have come to an end. Whoohoo!

Ok, great stuff! Finally your company is on the right path. Right after daily you hurry down to your desk again. Now let's do some bug hunting! You start to examine the class signatures involved in that nasty bug again:

public sealed class TimeServer {
  public TimeEntry GetTime();
}

public sealed class TimeEntry {
  public TimeEntry(LocalTime lt);
  public void Apply(CultureInfo ci);
  public void Ensure(CultureInfo ci);
  public LocalTime ToLocalTime();
}

public sealed class LocalTime {}

Wow. Sealed. The Dev who wrote this must have got a Kiss from a Rose. Looking back at the original Chronograph class, it's crystal-clear that the else branch needs to call Ensure instead of Apply. Pretty easy. But wait! How to write a test for this tiny typo? You look back into your digital toolbox: Only NUnit and Moq available. Hmm. You stop for a minute and rephrase the question in your mind: "How to write a sensible unit test beforehand to ensure that the bug is fixed right after you have just replaced a single word?"

The Quest Of The Test

You wouldn't be a geek if you wouldn't consider it as a duty to find an answer to this question. With years being in this business, you very surely know: There's coders, there's hero coders, and - there's you. The metaphorical ant of all coders. You'll sit here, with your coffee mug on your left, and take the quest. Duty is calling, comrade.

First, you just do the regular easy stuff. That is, get NUnit referenced, build up a skeleton of the test class and write up your environment to be "ready to assert". No minute later, you're staring at this code fragment:

[TestFixture]
public class When_chrono_is_in_sync {
  [Test]
  public void Then_culture_is_ensured_with_time_entry() {
    var ensureWasCalled = false;

    var ts = new TimeServer();
    var chrono = new Chronograph();

    chrono.IsDirty = false;
    chrono.SyncWith(ts);

    Assert.IsTrue(ensureWasCalled);
  }
}

So far, so good. Now the kindergarten is over. Right now is the time to separate real men from boys. You need to find a plausible and sensible way to express the expectation, that te.Ensure() is being called instead of te.Apply().

It's time for another coffee. Volluto doesn't do any more. This exceptional situation cries for exceptional coffee. You put in the "Roma" tab into the machine and let the mug do its job: awesome coffee storage. No milk. No sugar. Outlook off, Browser off, Tweetdeck off. You literally feel the scientific aura now.

"Wait a minute..." you think. "... scientific? Science. Yes, science is a good catch right now. I need to express a function in order to put it under assertion.". Express. A. Function.

Eureka!

That's the key! You'll go for a lambda expression. You need to define the function which actually calls the Ensure method and then assert its proper usage simply by checking whether this function has been called. That's like implanting a lambda into the existing code. You quickly smash in some prototypical code to verify your solution path:

public static class TimeEntryImplant {
  public delegate void Ensure(CultureInfo culture);
}

That's the delegate. Let's weave that into Chronograph in order to be able to utilize it:

public class Chronograph {
  private CultureInfo _culture = CultureInfo.InvariantCulture;
  private TimeEntryImplant.Ensure _implant;

  internal Chronograph(TimeEntryImplant.Ensure implant) {
    _implant = implant;
  }

  // ...
}

And finally heading on to extend the test:

[TestFixture]
public class When_chrono_is_in_sync {
  [Test]
  public void Then_culture_is_ensured_with_time_entry() {
    var ensureWasCalled = false;

    TimeEntryImplant.Ensure implant =
      culture
        => ensureWasCalled = true;

    var ts = new TimeServer();
    var chrono = new Chronograph(implant);

    chrono.IsDirty = false;
    chrono.SyncWith(ts);

    Assert.IsTrue(ensureWasCalled);
  }
}

"Yeah, right." Looks good so far. The strategy now is hacked in. You feel good, you feel confident. Nonetheless, you still feel the need to reiterate your solution path again. The pro is working here. Swiftly, almost gracefully, you stand up from your seat, followed by two elegant sidesteps towards the whiteboard. On a small space on the upper left corner you rewrite the essentials steps again:

1. Declare & define expression containing the new functionality.
2. Use the expression within assertion to get the test red.
3. Implant the expression within class under test to get the test green.

Freddy Fredpecker

"Hey, hey, heeeeeeey!" you hear a dark, arrogant and unemotional voice on your back saying with low voice. It's Fred, your "colleague". No. Collegue is not the right word. Fred is an arrogant Egomaniac, who coincidentally happen to work at the same company as you do. To make it even worse, Fred is the self-proclaimed "Testing Expert" in your department. He actually hasn't heard anything about MSpec, he writes "Unit Tests" with database usage and he is very keen to rigorously punish every developer with irony and sarcasm who is not obeying the almighty AAA-rule. Testing Expert, you know.

You turn your back slowly and see him sitting on your desk. "What an ignorant, low-life piece of crap he is" you think as you see him tipping with his dirty fingers on your beloved Octocat Mug while swinging around in lay-back mode on your swivel-chair.

"You seem to have a faible for testing, aren't you? Buddy, realize testing is not about colors or expressions. I see..." Fred continues while having a glimpse at your test code, "... you're trying to test something with lambda. Man, I knew you're crazy. Like 'Adam Sandler-Crazy'. But I didn't knew you're dumb as well. Like 'Jim Carrey-Dumb', y'know?" He harshly puts your mug back on your desk while moving his butt off your chair.

"Fred," you reply, "ehh... eh... well... em, you're right. I'm just trying out something, y'know? It's wrong shit anyway, so don't care about it. Well, y'know it's hard for me as an 'average' coder to get into this testing stuff. I'm experimenting a bit, that's all.".

You know you need to get rid of him. Now. You put that ordinary, demotivated Looser-Look on your face and stare at Fred. Deranged. - "You better get a life, kid." mouns Fred and slowly moves out of the door. You follow him, with a little, respectful distance, grab the knob of the door and close it silently.

Two Strikes To Green

"Phew... at least I got rid of this low life looser". You quickly move back to your desk and grab the keyboard. You're so close to the solution, only a few keystrokes away. The test is red. You know you could go green by just invoking _ensure function you injected through Chronographs constructor.

However, that's not the idea of this game. The Idea is to ensure that the real Ensure method of TimeEntry has been called. You lean back for a minute, then decide to slowly hack in an extension method to TimeEntryImplant:

public static class TimeEntryImplant {
  public static void EnsureImplant(this TimeEntry entry, CultureInfo culture, Ensure implant) {
    (implant ?? entry.Ensure)(culture);
  }
}

Yep. You pause. Just staring at your code. It's these little moments, these little seconds in your poor hacker life you're loving to have. You made it. And it looks beautiful. You just got your very first test implant.

Grande Finale

Now let's head on to the finishing move! It somehow amazes you that you're able to switch back into rapid fire mode so easily after being in the 'code monkey stares at code'-position. Rolling back with yout chair to your desk, you almost spilled your coffee on your beloved keyboard. Almost.

Ok. Concentration. You already know it. Victory is only one single line away. With the heart of a winner, a generous and confident smile in your face, you open the Chronograph class and change the line you knew you needed to change from the beginning. You locate your enemy:

te.Apply(_culture);

Squash this buggy line away and place in your implant:

te.EnsureImplant(_culture, _implant);

Save. Run test. This is the moment. You stare with eager into test results window while your stuff compiles. You're sweating, altough you haven't moved your ass even an inch away from your computer.

Ok, runner starting... testing... green!

Victory!

You lean back, grab your mug, sip a little bit, switch back to code to see the beauty of the complete Chronograph class:

public class Chronograph {
  private CultureInfo _culture = CultureInfo.InvariantCulture;
  private TimeEntryImplant.Ensure _implant;

  internal Chronograph(TimeEntryImplant.Ensure implant) {
    _implant = implant;
  }

  public bool IsDirty { get; set; }

  public LocalTime SyncWith(TimeServer ts) {
    var localTime = new LocalTime();

    if (IsDirty) {
      TimeEntry te = ts.GetTime();
      te.Apply(_culture);
      localTime = te.ToLocalTime();
    } else {
      TimeEntry te = new TimeEntry(localTime);
      te.EnsureImplant(_culture, _implant);
      localTime = te.ToLocalTime();
    }

    return localTime;
  }
}

You did it. You squashed the bug. TDD. Test-First. Brownfield. What a victory.

After this tremendous win, you surely got excited enough from your test implant to tell all your mates about it. In your office, though IM, Facebook, Twitter and whatever medium you have ready. For hours and hours, you reiterate your journey.

Through all this excitement, you even get your hands on other, similar pieces of code and try using the implant technique. It's easy, it's expressive, it just works.

After all these exciting hours, you literally didn't notice how fast time flew away. It's 9 P.M and you're still in office. "Oh shit, I'm supposed to meet with my honey at 10!". You grab your jacket, lock your box, switch off lights and slowly move stairs down to basement. Time to leave with pride. With the 'test implant' feather in your cap you walk out of the office and step into the bus.

An hour later you're finally at the bar to meet your sweetheart. She steps in, beautiful as ever, smiles and quickly skirrs into your arms. This day can't get better. She gives you a long, affectionate kiss - willing to stop at nothing.

All of a sudden you stop the kiss, smile at her at your best and whisper: "I love you, hon..." while thinking... "OMG, I forgot to check-in!"

Global Type Alias

First off, let me define what a global alias is for me. A global type alias is best described with the current aliasing feature in C#:

using System;
using Dump = System.Diagnostics.Debug;

public class Writer {
  public Writer() {
    Dump.WriteLine("Writer!");
  }
}

The second line is a using alias. It's quite handy to avoid name clashes in your source file. And that's the downside (for me) as well. In C#, it's only possible to define type aliases on source code file level. While it's perfectly ok for resolving name clashes, it's yet not enough for me in terms of sensible alias usage.

From my perspective, a broader - even declarable - scope of a type alias would be very helpful. As a starting point, I'll define a "global" type alias as an alias valid on assembly level.

Global type aliasing can be very helpful. I miss it most for generic types, since they're not only tend to be verbose but can be misleading as well. I mean, how often did you ask your inner self the famous three letters (WTF?) when seeing something like ServiceResponse<Dictionary<long, List<string>>>? Yes, sure you can alias it with using RoadServiceResponse = ServiceResponse<Dictionary<long, List<string>>>.

Now would you want to define this alias in every single file where you process this mighty response object? Surely not. Redundancy is boring. However, if you're using C#, you just have to. A widely scoped type alias is surely possible if you were using VB.NET with its Imports feature.

Alias Open Types

Lengthy and complicated naming is one reason. A second, even more demanding reason for global type aliases are the use of generic implementations or generic interface definitions. It may sound weird in first instance, so let's see an example here:

/* Assembly A: My 'cool' API :-) */
using System;
using System.Collections.Generic;

public interface IMetaData<T> {
  string Id { get; }
  T Data { get; }
}

public interface IRelationMap<T, TKey, TValue> 
  : IDictionary<TKey, TValue> {
  TValue GetRelated(T obj, TKey key);
  T RelateTo<T>(TKey key);
}

public interface IMetaInfo<TSource, TData> {
  IRelationMap<TSource, string, IMetaData<TData>> Properties { get; }
  TSource Object { get; }
  int ChannelId { get; }
}

A little unreadable for the generic types, but quite straight forward so far. Let's implement IMetaInfo:

/* Assembly B: My 'cool' Service :-) */
public class TextMetaInfo<T> 
  : IMetaInfo<T, string> {
  public IRelationMap<T, string, IMetaData<string>> Properties { get; set; }
  public T Object { get; set; }
  public int ChannelId { get; set; }
}

Doesn't this look weird? Wouldn't this one be a little more readable:

using System;
using System.Collections.Generic;

using IMetaMap<T> = IRelationMap<T, IDictionary<string, IMetaData<string>>;

public class TextMetaInfo<T> 
  : IMetaInfo<T, string> {
  public IMetaMap<T> Properties { get; set; }
  public T Object { get; set; }
  public int ChannelId { get; set; }
}

Sad enough that above code won't compile. C# only accepts aliases for closed types.

Yeah, you might think now that this is just nitpicking, since you surely might just derive to have naming done right:

public interface IMetaMap<T> : IRelationMap<T, IDictionary<string, IMetaData<string>> {}

Sorry to disappoint you here. "Fixing naming" by subclassing is just wrong. Despite of the bad smell you simply made it even worse since you now made it a lot harder to implement IMetaInfo<T, string>. If you were the consumer of Assembly A without any source code access, you lost anyway. If you actually have access to the sources of Assembly A, you end up in deciding whether to change the type signature of IMetaInfo<TSource, TData> just for naming. In consequence, other implementors need to change their implementations. Even callers need to recompile. For the sake of readability?

Sorry, C#. You are doing a good job being a multi-paradigm (yet OO-colored) language. However, when it comes to aliasing, you could do better.

Titel: Amigo Agilo: Alles Agil, Nichts Stabil

Beschreibung: Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Stabil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Stabil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Stabil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Stabil. Agil. Agil. Agil. Agil. Agil. Agil.

Interesse? Interesse!

Ich möchte hiermit jeden, der Interesse an meinem Beitrag "Amigo Agilo: Alles Agil, Nichts Stabil" hat, um einen Gefallen bitten:

Bitte schreibt mir hier einen Kommentar, twittert an @ilkerde, schlagt meinen Vortrag auf Konferenzen, Barcamps und User-Groups im Software-Entwicklungs- und Software-Management-Umfeld vor. Ich würde mich sehr freuen, diesen Beitrag einem breiten und interessierten Publikum vorzustellen.

Jede aufrichtige und realistische Möglichkeit nehme ich dankend an. Ganz besonders würde es mich freuen, diesen Vortrag im Rahmen einer Konferenz oder eines UG-Treffens für Agile Methoden halten zu können. Das ist ja bei dem Thema ja recht naheliegend, oder?

Bevor es zu irgendwelchen Mißverständnissen oder Rückfragen kommt: Der o.g. Titel sowie die ungewöhnliche Beschreibung dazu sind alles, was ich zum Beitrag schriftlich mitgeben kann und will. Die Beschreibung trifft den Vortragsinhalt ziemlich genau, denn es geht um das Wort "Agil" und dessen Bedeutung im Software-Entwicklungs- bzw. -Management-Umfeld.

Die Dauer des Vortrages ist ca. 60 Minuten, es sind keine Voraussetzungen notwendig, außer ein gesundes Interesse zum Thema. In diesem Sinne:

Alles Agil, Nichts Stabil.

Ich freue mich auf Feedback, Meinungen und Anregungen. Danke.

Notizen eines Nerds

• UX: Progressbar vs. Waitcursor
• Code Analysis Notes
• Hardcore Software
• ALE MUC Brainstorming
• XP Secrets Notes
• TDD Talk Notes
• Die Modellverantwortung des Architekten
• Castle Of Variability & Estimation
• Branching Patterns
• Context In Model Is Evil
• Menu State Analysis
• Posh 4 Devs Notes

More Nerd Notes

Der aufmerksame Leser meines Blogs kennt sicherlich auch die "Vorjahres-Ausgabe" meiner Nerd-Notizen, nämlich die Notizen eines Nerds 2010.

Meine Notizen fertige ich in meinem kleinen Moleskine an. Es passt in jede Hosentasche und ist bei mir (fast immer) griffbereit. Dann brauche ich nur noch einen Bleistift, interessante Themen und Ideen. Ab und zu klappt das auch.

Mir hat mein kleines Notizbuch immens geholfen. Beim arbeiten, planen, begreifen, designen, reflektieren, lernen, denken und entspannen.

Ich wünsche uns allen gemeinsam ein gesundes, frohes, glückliches und erfolgreiches Jahr 2012!

Eines der jüngeren Vorträge in meiner Vortragsliste ist der Beitrag Posh 4 Devs, auf gut Deutsch: Powershell für Entwickler. Ich habe den Vortrag schon halten dürfen und war froh über das positive Feedback.

Gerade auch, weil ich die Powershell selbst nicht mehr so intensiv nutze, sondern eigentlich nur noch für Automatisierungen in meiner Arbeitsumgebung. Die Notiz zur Vortragsgestaltung sieht bei mir so aus:

Ich habe während der Umgestaltung meiner Website mehrere Menü-Navigationen entworfen und umgesetzt. Die Navigationsmodelle habe ich mit Status- und Pfad-Diagrammen analysiert und bewertet. Naja, auch so etwas muss mal sein.

Ich kann es eigentlich nicht oft genug betonen. Das Wörtchen Kontext hat in einem objekt-orientierten Domänenmodell nichts verloren. Nicht einmal in einem technischen Framework. Wenn jemand objekt-orientiert modelliert und designed, dann bitte ohne "Kontext-Objekte". Danke.

Branching. Dieses Thema geht an keinem Entwickler vorbei. In den letzten Jahren habe ich so oft (und immer wieder) über Branching, Branching-Strategien und Patterns gelesen, studiert, probiert und umgesetzt. Mit großen Code-Ständen, sehr großen Code-Quellen und auch kleineren Repositories. Auch in diesem Jahr gab es wieder etwas "zum Branch":

Es war einmal ein Schloß. Dieses Schloß war das sogenannte "Schloß des Kaisers von Digitalia", dem unendlich großen Reich der Software-Entwicklung und des Managements. Der Kaiser hatte zu seiner Belustigung bei Software-Projekten immer zwei Junker zu seiner Seite.

Der erste Schelm hörte auf den Namen "Variability" (Variabilität). Er war ein freudiger kleiner Narr, der besonders stetig und zuverlässig eine maßvolle Bespaßung der kaiserlichen Umwelt umsetzen wollte.

Der zweite Schalk war der überall bekannte "Estimation" (Schätzung). Ein juchzend-froher Kasperle, der sich um die kaiserliche Freude durch verblüffendes und deutsames Lustspiel rührend kümmerte.

Beide waren sich Ihrer Aufgabe und Verantwortung gegenüber dem Kaiser und dessen Reich bewußt. Beide wollten der bessere Harlekin sein. Der Kaiser jedoch, der Kaiser... der lachte über beide Narren.

Diese Nerd-Notiz ist noch ein kleines Stück persönlicher als die anderen. Es geht um Software-Architektur. Besser gesagt, es geht um den Architekten - und dessen Verantwortung der Software und dem Team gegenüber.

Ein weiterer Beitrag von mir ist TDD - Teilen, Denken, Designen, welches ich mit Freude auf der .NET DevCon vortragen durfte. Regelmäßige Leser meines Blogs werden wohl meine Affinität zum Thema TDD mittlerweile kennen.

Umso mehr war es für mich eine Freude und eine Aufgabe gleichermaßen, in dem Vortrag die Vorzüge von TDD dem Publikum näher zu bringen. Ich hoffe, es ist mir gelungen. Auch hierzu habe ich viele Seiten in meinem Notizblock vollgekritzelt. Stellvertretend hier eine Ablichtung der ersten Seite:

Im Mai hatte ich mindestens ein F wie Fun. Der Grund: ich war als Sprecher bei dem .NET Day Franken mit dabei und hatte die Freude, meinen XP-Secrets Vortrag zu halten. Ich habe gutes und positives Feedback bekommen, was mich besonders gefreut hat. Hier die erste Seite (von vielen) meiner Notizen zu dem Vortrag.

Im Frühjahr hatte ich das Vergnügen, mich mit @wwiedenroth und @da_chrisch gemeinsam zum Brainstorming der Interessensgemeinschaft ALE Network Munich zu treffen. Es war ein sehr konstruktives und inspirierendes Gespräch.

Uns Drei hat die Idee der autonomen, nicht-regulativen Interessensgemeinschaft für Agile, Lean und das Drum-Herum so gut gefallen, dass wir uns dafür engagiert haben, die Münchener Gemeinde rund um AgileTuesday, Scrumtisch und Limited WIP Society zu einem Ideen- und Meinungsaustausch einzuladen.

Während der Brainstorming-Session mit Wolfgang und Christian habe ich mir (wie üblich) Notizen gemacht. Es war ein sehr lehrreicher Abend. Obendrein habe ich auch noch zwei agile Freunde kennen - und schätzen - gelernt.

Ein Thema, welches sowohl Entwickler als auch UI-Designer mit Sicherheit begegnet sind oder werden: Wartezeit. Warten ist ein heikles Thema. Ganz besonders, wenn es um Computerprogramme geht.

Das klassische Thema heißt dabei: Progressbar vs. Waitcursor. Fortschritt oder Warteschleife.

Ich bereite meine Vorträge mit verschiedenen Werkzeugen und Techniken vor. Ein Mittel, welches ich quasi immer einsetze ist ein "Transscript", welches in kurzen Stichpunkten den Ablauf des Vortrages widerspiegelt. So auch bei meinem Vortrag über (statische) Code-Analyse, auch "Code Reading" genannt.

Alleine in den letzten 2 Jahren habe ich locker ein halbes dutzend Mal Kunden und Teams zu diesem Thema beraten.

Das frappierende dabei: fast jedes mal mussten die absoluten Grundlagen vermittelt und durchgearbeitet werden. Ich erwarte ja nicht, dass alles schon picobello umgesetzt ist. Aber es ist heutzutage gar nicht mehr so schwer, die fundamentalen Grundlagen in die richtige Richtung zu lenken. Es scheint wohl doch nicht immer zu gelingen, wie mehrfach meine Erfahrung mich belehrte.

Prolog

So. Um nun nicht immer wieder von Null anfangen zu müssen, veröffentliche ich hier ein original Statement-Papier zum Thema "Code Quality KPI's". Es wurde von mir für einen Kunden als erste Antwort auf seine bisherige "KPI-Strategie" verfasst. Der folgende Text ist O-Ton aus einer Antwort-Mail.

Nomenklatur

Die "Strategie-Aussagen" des Kunden habe ich als Zitate angeführt.

Beispiel:

Aussage: Code-Qualität ist wichtig für den Projekterfolg.

Die eben zitierte Aussage stellt ein "Strategie-Aspekt" dar, den ich hier - im Freitext - behandle bzw. erwidere.

Motivation

Das ganze mache ich in der - wohl eher idealistischeren - Hoffnung, dass sich einige Software-Projekt-Manager oder Entwicklungsleiter hierher verirren und sich mit den Grundlagen der Messung von Codequalität zumindest auseinandersetzen.

Denn wenn die Grundlagen schon mal sitzen, dann kann man auch wesentlich entspannter und effektiver an der eigentlichen Qualitätserhebung arbeiten.

Abgrenzung

Der gleich folgende Abzug meiner Antwort auf ein KPI-Strategie-Papier ist mit nichten als eine vollständige "Code Quality Metrics"-Strategie zu bewerten. Im Gegenteil. Meiner Meinung nach fehlen gerade im folgend gezeigten Diskurs wesentliche Elemente einer Qualitätserhaltung, -messung und -bewertung im agilen Sinne.

Nichtsdestotrotz belasse ich es bei meiner Antwort auf die u.g. KPI-Ideen. Der Blog-Artikel ist so schon lang genug. Darüber hinaus ist mein Ziel ja auch nicht das Aufzeigen aller Grundlagen zur Qualitätsmessung, sondern eben nur derjenigen, die sich immer wieder als "die üblichen Verdächtigen" hervortun.

In diesem Sinne, jetzt und hier:

"What you as a Developer, Tester, Manager or Leader should absolutely know about code quality measurement, indicators and their impact."

Viel Spaß.

Quality Values

1. Code Base Maturity

Ein stetig grüner CI-Build ist Indikator für die Stabilität der Software. Wir werden alle Buildergebnisse des CI nach Erfolg und Mißerfolg bewerten, um einen stabilen CI-Build als Grundlage zu gewährleisten.

Zu 1) Ich gehe davon aus, dass hier jeder rote Build mit einer Qualitätsminderung assoziiert wird. Im Gegenzug soll wohl hier ein stetiger Build-Erfolg ein Qualitätsmerkmal abbilden.

Es ist für das Ziel einer "Mature Code Base" für mich nicht direkt erschließbar, warum gerade ein stetig grüner Build von einer "erwachsenen Codebasis" Zeugnis tragen soll.

Vielmehr ist ein grüner CI ein Abbild der Sorgfaltskultur des Teams. Das allerdings auch nur, wenn eine rege Check-In-Kultur herrscht (in Kombination mit anderen Faktoren, selbstverständlich).

Eine strikte "Stay-Green"-Politik des Builds kann Gefahren mit sich bringen. Einerseits kann das Team zur Erhaltung der KPI auf Branches oder Shelves ausweichen. Andererseits ist auch eine "Check-In-Angst" in Folge des KPI-Drucks denkbar.

Das würde dem Qualitätsbestreben entgegenstehen, zumal eine lange "Vorhaltezeit" von Code-Änderungen zu größeren Commits, schwierigeren Merges und schlechterer Integration führen.

Es kann durchaus zur Folge haben, dass Commits auf die lange Bank geschoben werden, welches dann typischerweise am Ende der Iteration zu potenziellem "Commit-Stau" und Irritationen beim Merge führen kann.

Ich sehe diesem KPI mit äußerst kritischem Blick entgegen.

2. Architecture Conformance

Eine automatisierte Prüfung der Abhängigkeitsbeziehungen der System- und Softwarekomponenten wird stetig mit den architektonischen Vorgaben korreliert. Somit lassen sich Abweichungen gegenüber der Systemarchitektur feststellen und beheben.

Zu 2) Die Annahme hier ist: geringere "Abhängigkeitsverletzungen" der Zielarchitektur können einen höheren Qualitätsspiegel darstellen.

Meines Erachtens ist das durchaus ein guter Indikator für Stringenz und Konventionstreue gegenüber der Zielarchitektur. Besonders beachtenswert ist es hier meiner Meinung nach, dass Architekturen durchaus einer "stetigen Bewegung" ausgesetzt sind - sich ergo im Laufe der Zeit verändern.

Unter dem Vorbehalt der individuellen Betrachtung der einzelnen Architekturbestandteile kann hier ein Messwert ein Indiz für ganzheitliche Systemkonzeption und -umsetzung sein.

Ich kann aus meiner Perspektive noch die Messung der Änderungs- bzw. Ergänzungsfrequenz der Architekturrichtlinien zweifelsfrei empfehlen. Es gibt Aufschluss über den "Architektur-Puls" - also der Beschäftigung mit der Gesamtkomplexität des Systems.

3. Standards and Best Practices

Der gesamte Quellcode wird nach den üblichen Standards und Best-Practices wie Methodenlänge, Dateilänge sowie Code-Duplikate bemessen und bewertet werden.

Zu 3) Der Überbegriff ist hier für meine Begriffe mit zu viel Interpretationspotenzial behaftet. Mein Verständnis ist hier, dass die Pflege von Source Code nach "etablierten" Qualitätsmerkmalen wie z.B. Dateigröße oder Methoden-Länge eine allgemeine Verbesserung der Produkt-Qualität nach sich zieht.

Ich finde, eine Messung solcher "Best Practices" kann durchaus hilfreich sein und auch ableitbare Informationen über die Entwicklungs-Qualität geben.

Wichtig ist für mein Dafürhalten hier, dass die Werte für sich alleine zumeist kaum Aussagekraft mitbringen.

Vielmehr ist es so, dass zumindest Volumen-Indikatoren wie z.B. Anzahl der Code-Zeilen (LoC) oder Anzahl der Typdefinitionen (Class Count) in Korrelation gestellt werden müssen, um aus den einzelnen Metriken ein grobes Bild über das Pflegepflichtbedürfnis des Teams zu zeichnen.

4. Unit Testing

Die Anzahl und Abdeckungsdichte von Unit-Tests ist ein weiteres, wesentliches Merkmal für die Messung der Software-Qualität.

Zu 4) Zweifelsohne sind lauffähige, positive Testprogramme für das Produkt ein Qualitätsmerkmal. Ich kann das Bestreben nach "Unit Testing" nur vollends unterstützen. Dennoch gibt es schon einige Punkte, die meiner Meinung nach einer genaueren Betrachtung bedürfen.

"Unit Test" ist ein weitläufiger, technisch geprägter Begriff, der auch einem breiten Spektrum von Test-Konzepten genügen kann.

Das ist meiner Meinung nach als Schwachpunkt zu deuten - ganz besonders, wenn es um die Erhebung von Metriken geht, bei der von Natur aus präzisere Messmöglichkeiten wünschenswert sind.

Ich rege zumindest eine weitere technische Unterscheidung zwischen Integrationstest und komponenten-orientiertem Funktionstest an. Während der Integrationstest (auf verschiedenen Ebenen) das reibungslose Zusammenspiel der Komponenten adressiert, ist der Funktionstest auf das korrekte funktionale Verhalten einer einzelnen Komponente - sprich: Klasse - konzentriert.

Im englischsprachigen Raum wird im Übrigen genau der Funktionstest oftmals als "Unit Test" bezeichnet, was sicherlich nicht zu einer klaren Abgrenzung der Test-Ansätze beiträgt.

Abgesehen von diesem - sehr weiten - Themenbereich kann ich den KPI mit einem freudigen, als auch einem kritischen Auge betrachten. Einerseits ist es wichtig und richtig, die Stabilität des Unit Tests im CI-Build zu beobachten. Andererseits ist eine ausschließliche Betrachtung der "Green-Rate" von Tests aus meiner Sicht mit schweren Deutungsvarianzen und einer latenten Abbildungsschwäche behaftet.

Es hilft aus meiner Sicht vielmehr, die Anzahl der Tests in Relation zum Code-Volumen zu beobachten. Daraus lässt sich tendenziell die Aktivität des Teams hin zu Testbarkeit und "Test-Awareness" beobachten.

Darüber hinaus ist vor Allem bei der "Stabilität" von Tests nicht nur deren Erfolgsrate wichtig, sondern auch deren "Anschlagsrate". Ein Unit Test, der in Folge einer Regression fehl schlägt, ist für das Team als auch für das Produkt als Erfolg zu werten, weil er seinen Dienst der Überprüfung und Warnung verrichtet hat.

Ein weiterhin erwägenswertes Merkmal ist sicherlich die Dauer der roten Warnphase, in der ein Test fehlgeschlagen ist. Sie ist ein Zeichen für das verantwortungsbewusste Qualitätsempfinden des Teams. Eine kurze "Red-Response" ist ein hohes Gut für eine qualitätsorientierte, stetige Software-Entwicklungsmethodik.

Die zweite vorgeschlagene Metrik der "Code Coverage" ist - wie auch das Unit Testing selbst - eine Medaille mit zwei Seiten. Die Theorie der Testabdeckung besagt nämlich lediglich, dass der betroffene Code unter eine Testbedingung gestellt wurde. Das kann für eine strengere Qualitätsbetrachtung zuweilen schon nicht mehr hinreichend sein. Ich persönlich schätze die Aussagekraft einer Testabdeckung in Relation zum gesamten Code-Volumen als schwach und unpräzise ein.

Nichtsdestotrotz kann mit einigen Ergänzungen eine Testabdeckungsmessung nicht nur eine (begrenzte) Aussage über die Test- und Produkt-Qualität geben, sondern auch als anregender Katalysator hin zu einer manifestierten Testkultur betrachtet werden.

Eine hilfreiche Ergänzung ist die Definition und das Festhalten der Testabdeckungs-Ratio in Relation zu technischen und fachlichen Komponenten. Auf Grund einer technischen Architekturbetrachtung ließe sich eine technische Risiko- und Lebenszyklusbewertung vornehmen, die man in die Abdeckungsgewichtung einfliessen lassen kann.

Viel wichtiger ist aus meiner Sicht jedoch die Wertbetrachtung der fachlichen bzw. funktionalen Komponenten und deren Einbeziehung in die Testabdeckungszielsetzungen.

Eine tragende fachliche Kernkomponente kann durchaus mit intensiven Testbemühungen begleitet werden, um das Risiko einer Fehlfunktion sowie eines fachlichen Fehlverhaltens zu mitigieren.

Hier kann eine Testabdeckungs-Ratio von 98% oder mehr eine realistische als auch notwendige Zielbindung darstellen. Bei einer fachlichen Funktionalität geringerer Tragweite sowie technisch minder komplexen Szenarien wie zum Beispiel der Darstellung von Ergebniswerten kann eine (deutlich) mindere Testabdeckung vertetbar, ja sogar zweckgemäß sein.

Alles in Allem ist meine Perspektive zu diesem "KPI-Paket" eher positiv. Nicht zuletzt, weil es eine (kurzfristige) Anregung hin zu einer soliden, eigeninitiatorischen Testkultur darstellen kann.

Ich will dabei jedoch auf keinen Fall meine Bedenken in den Hintergrund rücken, sondern eher zur Erweiterung und stetigen Verbesserung im Bereich "Unit Testing KPI" ermutigen.

Quality Metrics And Impact

1. Impact Of Architecture Dependency Analysis

Eine Einhaltung der Architektur-Vorgaben wirkt sich positiv auf die Erweiterbarkeit, Testbarkeit und Skalierbarkeit des Systems aus.

Zu 1) Alle drei nicht-fachlichen Werte können durch eine stringente Umsetzung von Architektur im komponenten-orientierten Sinne gestärkt werden. Bei der Testbarkeit kommt es sicherlich auch auf die Granularität der Verantwortungsteilung im OO-Design an.

Die Wirksamkeit zu verbesserter Skalierbarkeit hängt hierbei jedoch aus meiner Sicht in großem Masse von der Zielarchitektur ab, als ausschließlich von der Umsetzungstreue von Architekturvorgaben.

Eine meiner Meinung nach wichtige, jedoch unerwähnte Auswirkung ist die Bewältigung von fachlicher Komplexität sowie der daraus sich ergebenden verbesserten Wartbarkeit.

Bekannte und konventionalisierte Architekturmuster helfen, sich in komplexeren Interaktionen und Konstruktionen schnell wiederzufinden und zu orientieren.

2. Impact Of Unit Test Coverage

Eine höhere Testabdeckung des produktiven Quellcodes gewährleistet Erweiterbarkeit und Testbarkeit des Systems.

Zu 2) Die Metrik der Testabdeckung stellt streng genommen wohl kaum eine Auswirkung auf Erweiterbarkeit dar. Auch Testbarkeit kann nur in geringem Maße ein direkter Wirkungsmechanismus von Testabdeckung sein.

Oft können mit wenigen Integrationstests viele Codebereiche abgedeckt werden, die keiner effektiven Erweiterbarkeits- oder Testbarkeitsbetrachtung genügen würden.

Im Sinne der nicht-fachlichen Qualitätsmerkmale ist meiner Meinung nach eine Testabdeckungs-Metrik ein äußerst schwacher Wirkhebel für Testbarkeit, Sicherheit und Stabilität.

3. Impact Of Compiler Warnings

Durch eine konsequente Vermeidung von Compiler-Warnungen wird eine deutliche Senkung der allgemeinen Fehlerrate gewährleistet.

Zu 3) Unter der Berücksichtigung der vorgegebenen Einstellung "Treat Warnings as Errors" in C#-Projekten kann ich die Wirksamkeit auf verminderte Fehlerrate kaum einschätzen.

Da sie allerdings nur in besonderen Konstellationen (wie dem bekannten [Obsolete]-Warning) als hinderlich betrachtet werden kann, ist aus meiner Sicht eine besondere Beachtung der "Compiler Warnings" zumindest nicht von Schaden.

Indirekt kann man sogar durch einen strikteren Umgang mit Compile- und Buildergebnissen die Wachsamkeit und Wartungsverantwortung des Entwickler-Teams unterstützen. Insofern ließe sich zwar eine verbesserte Wartbarkeit ableiten, die jedoch weder direkt noch mit entscheidender Wirkungskraft einzustufen wäre.

4. Impact Of Duplicates

Durch gezielte Vermeidung von Code-Duplikaten wird die allgemeine Fehlerrate gesenkt und die Wartbarkeit des Systems deutlich gesteigert.

Zu 4) Das Thema der Code-Duplikate ist im Entwicklungsumfeld sehr weit verbreitet und bekannt. Der gemeine Konsens ist hier, nach einer Vermeidung von Duplikaten zu streben, zumal sich dadurch Funktionalität dupliziert. Als Konsequenz steigt die Wartbarkeit, Stabilität und Sicherheit.

Ich kann im Allgemeinen eine Beobachtung der Code-Duplikate empfehlen. Die Metrik sollte in Relation zum Gesamtvolumen betrachtet werden.

Darüber hinaus ist es besonders empfehlenswert, eine "Abstandsmessung" von Duplikaten vorzunehmen. Hieraus kann in vielen Fällen auch der tendenzielle Verminderungswiderstand erkannt werden.

5. Impact Of File Size

Durch die konsequente Begrenzung der Dateigröße einer Quelldatei kann die Komplexität des Systems begrenzt werden und die Wartbarkeit gesteigert werden.

Zu 5) Der direkte Bezug von Dateigröße zu fachlicher oder technischer Komplexität - wie sie hier erwähnt wird - erschließt sich mir auf den ersten Blick nicht verständniswirksam.

Vielmehr ist mein Eindruck, dass die Dateigröße als Volumen-Merkmal von Organisationseinheiten im Besonderen zur Wartbarkeit des Systems beitragen. Die Folge einer "überschaubaren" Organisationseinheit ist sicherlich der erleichterte Umgang mit dieser.

Eine Verringerung der Komplexität dieser Einheit - also der Klasse - ist bei distanzierter Betrachtung auch in vielen Fällen ersichtlich - jedoch nicht kausal auf einen restriktiven Umgang mit Dateigröße zurückzuführen.

Dennoch können kürzere Dateilängen sich indirekt auf die Komplexität vorteilhaft auswirken, zumal durch den "Organisationszwang" auch bedingt ein Aufbruch der Komplexität in einzelne Teilprobleme gefördert wird.

Insofern kann ich die Dateilänge als Qualitätsmerkmal schon nachvollziehen. Bezüglich der Aussagekraft der Metrik ist allerdings meiner Meinung nach Vorsicht und Augenmaß geboten.

6. Impact Of Length Of Method

Eine strikte Begrenzung der Methodenlänge wirkt sich komplexitätsmindernd und damit qualitätssteigernd aus.

Zu 6) Die Länge einer Methode hat aus meiner Sicht eher einen indirekten - ja sogar schwachen - Bezug zur Komplexität. Im Allgemeinen sind "längere" bzw. "ausführlichere" Methoden weniger Komplex, sofern sie sich um eine Verantwortlichkeit kümmern.

Es ist schlußfolgernd eher das Single Responsibility Principle und die Separation of Concerns für die Minderung von Komplexität im Methodenbereich hilfreich.

Einen direkten Bezug bei der Methodenlänge sehe ich persönlich in der Wartbarkeit. Durch knappe und aussagekräftige Methoden lassen sich Aktivitäten schnell in fachliche Einzelkomponenten einteilen. Das wiederum fördert das Verständnis gegenüber der Fachlichkeit.

Eine Beobachtung der Methodenlänge als Qualitätsmerkmal ist sicher sinnvoll, wenn auch nicht so stark in der Aussagekraft wie z.B. die Verschachtelungstiefe.

7. Impact Of Nesting Depth

Durch konsequente Eingrenzung der erlaubten Verschachtelungstiefe (Nesting Depth) wird eine deutliche Komplexitätsminderung erreicht.

Zu 7) Die Verschachtelungstiefe ist in meinen Augen ein starker Indikator für Komplexität struktureller, imperativer Programme.

Die sog. "Branches" und "Loops" sind essentielle Programmsteuerungs- und -verarbeitungselemente, die ein Indiz fuer gesteigerte Komplexität des gesamten Aktivitätsablaufes darstellen.

Je eher und treffender es dem Programmierer gelingt, fachlich aussagekräftige Abstraktionen anzuwenden, um so geringer fällt im Allgemeinen auch die Verschachtelungstiefe innerhalb einzelner Aktivitäten aus.

Die Metrik ist für mein Dafürhalten ein starker und relativ zuverlässiger Indikator für fachliche und methodische Komplexität.

Code Review

Jede Code-Erstellung oder -Änderung soll durch ein Code-Review von einem weiteren Entwickler beurteilt und für gut befunden werden.

Dieser letzte Punkt der Strategie-Eckpfeiler ist aus meiner Perspektive eines der effektivsten Qualitätssicherungsmaßnahmen. Mit Sicherheit sind auch die o.g. KPI-Metriken für eine Qualitätsaussage relevant.

Jedoch ist in vielen Fällen eine individuelle und eingehende Betrachtung der Quellen für die allgemeine Qualitätsverantwortung deutlich förderlicher.

Alleine durch die Aktivität des "Reviews" wird so meiner Meinung nach der Qualitätsanspruch als allgegenwärtige Zielsetzung in die Teamkultur integriert.

Dadurch wird das gemeinsame Qualitätsbild (und die daraus abzuleitenden Ziele) geschärft. Ein weiterer positiver Effekt ist die implizite Verantwortungsverteilung zu Code-Quellen. Sowohl der Verfasser als auch der Rezensent tragen Verantwortung für die Qualität und Konventionstreue des Codes.

Ein etwas schwächerer, aber dennoch zuweilen merkbarer Effekt ist in diesem Zuge auch der fachliche und technische Wissenstransfer, der mit der Rezension des Codes einhergeht.

In Summe ist meiner Meinung nach die Etablierung von Code Reviews ein sehr nützliches Mittel für den Erhalt von Qualitätsstandards.

Epilog

So. Hoch lebe die "Messbarkeit" von Code-Qualität. Wer es in diesem Blog-Artikel bis hierher geschafft hat, hat es auch verdient, eine kleine grundlegende Abschlußbemerkung zu lesen. Ich erlaube mir ein wenig "aus dem Nähkästchen" zu plaudern.

Es ist meiner Meinung nach besonders wichtig zu erkennen, dass die Code-Qualität nicht beim Code, sondern bei den Entwicklern des Codes beginnt. Gerade deswegen ist es bei einer Strategie zur Erhebung eines Qualitätsniveaus wichtig, auch individuelle Betrachtung der Fähigkeiten und Prinzipien der Entwicklungsmannschaft mit einzubeziehen.

Die hier gezeigte Diskussion über automatisierte Code-Metriken können allemals als Hilfswerkzeug oder Indiz für eine Qualitätsaussage dienen. Einem Anspruch der effektiven Qualitätsmessung werden automatisierte Code-Metriken mit Sicherheit ungenügend gerecht.

If you care about quality, care about your people.

Granted, business life is neither a kindergarten nor a great party. However, that's not the point. Nobody wants to go for any extreme, me thinks. At the end of the day, it's the sustainable, solid productivity of yours what really counts for both you and your company. Hence, joy is a fundamental, yet far undervalued aspect of our daily work.

I want to share with you two little examples how you as a software engineer can improve your daily work by bringing back a little bit of joy to your desk.

Arabesque Coding

The first technique is what I call arabesque coding. "Arabesque" is an oriental artful painting style which uses ornaments to beautify the main theme of the painting. Consequently, arabesque coding is the activity of styling, formatting, documenting or in some other form enhancing the code you are currently working on.

It's important to notice at this point that arabesque coding mode is not intended to be applied all the time or on all your working items. The real beauty and joy of arabesque code is that it's embedded in an environment - a frame - of "normal, everyday" code. It's like a little gimmick in your code-base.

Performing arabesque coding is fun and can add some joy to tasks you normally do by routine. Interestingly, arabesque coding fits quite well on even more complex coding or design scenarios because it stimulates your creativity. I prefer arabesque coding in pair programming sessions but equally do it on my own as well. Most often I start to pick a little theme I'm interested in.

Here's a little example of arabesque coding. A few months ago @lennybacon came over to Munich to visit me. We had quite a lot of things we wanted to achieve within just a weekend. Discussing architecture, designing solutions and of course coding them into what makes all this effort worth: executable software solving the domain problem.

One of our tasks was to develop a prototypical tagging solution for communityblendr, a project @lennybacon is very enthusiastic in. The "tagger" should be able to tag "any" object with keywords. So we did a quick design session (using just code) and went over to implement it after verifying that our approach is doable.

It was a sunny afternoon and we just returned back from a short lunch. At lunch, we were talking about the "bavarian" style of living. While we were coding some tests for tagger, we decided to switch the syntax of our testing class to "boarisch" (which means bavarian, by the way).

Holy cow, that was fun! We laughed and joked all the way while we were developing the tagging library.

The morale here is not to make fun of engineering, but keep engineering enjoyable. Apart of the fact that every piece of software which actually solves a problem is enjoyable to us passionate developers, we can bring joy on the path towards the solution as well.

Easter Egg

Another recreational, enjoyable and very productive recipe is to build an easter egg into software. I'm quite sure that (almost) every developer knows what an easter egg is and might have seen an easter egg as well. The more I'm quite surprised how rarely easter eggs are being developed in our professional life.

Let me get one thing very straight: I'm not talking about spending valuable time and money to create useless, yet funny but hidden functionality. I'm talking about easter eggs. Easter eggs are little programs inside programs - at least in enterprise / consumer software. Very few developers actually know that the primary intent of an easter egg is to make development a little more enjoyable.

I frequently write easter eggs. I'm not writing them with every project I'm working on, yet I'm quite used to write them, to be honest. My easter eggs range from "very tiny" things up to "considerable work": ascii art banner, puzzle, calculator, wheel of fortune, clock and "weird translations".

Interestingly, I often find people having a very wrong sense of what easter eggs are. Mostly, they're undervalued as "just for fun" or plain "waste of time". That's simply wrong. Writing an easter egg is a recreational and relaxing task for developers. Just to recharge batteries. To shortly swift away from the big project to a very small and easy task.

Especially senior developers recognize the great power of easter eggs. Easter eggs help developers to gain a little distance from the daily challenges. Not as a door to escape from trouble or stress, but rather as a tool in order to refocus for the big project and big challenges. It's like having a break and a little walk in the park. Hence, it's not very important to have an easter egg done or published. The important thing with easter eggs is that you just have an easter egg to chew on.

That's why I certainly won't tell you in what (partly even publicly available) software you can find my easter eggs :-). Nonetheless, I want to conclude my post with a little "real life example".

Not very long ago, I worked on a web project with heavy javascript usage. We had to implement quite complex UI logic in order to create a compelling user experience. While I was coding the javascript bits with another (senior) engineer, we fiddled around with Firebug and did some JS-debugging.

At that time, we both were talking about the "good ol' times" where we both used to hang around on Quake Servers and performing some DMs in Q3DM17 and Q3DM6 maps. It was funny to see that we both had the "same habits": Using rocket launcher for the tricky moves and the famous rail for precise frags. We literally heard the dark dry-witted comments in out heads again: "Excellent!".

An easter egg was born. We decided to write a little "shell" into our javascript UI code which actually looks like the famous Q3 shell. Alongside, we agreed to enrich our logging with some bold comments by Hunter, Major and co. You can have a look at the very first code bits of "q3sh" (Quake 3 Shell), which we later got completed and integrated into the project (and never took out up until today).

We had a great time working together on the shell. Mostly, we worked on the shell at evening hours to cool down after a day working on heavy issues or features. The shell literally was a little "hideout" for both of us to relax and "reboot our minds". Apart of that, it helped us equally good on improving our "production" javascript codebase.

Enjoy Engineering

I love to develop software. I love to design it, I love to code it, I love to document it. I even love to use it. However, as a professional, I'm developing software all the time. Whether it is planning, estimating, designing, testing, coding, documenting, administering or using it. A professional job is not always love, peace and harmony. There's tough times as well. That's very normal, by the way.

As a professional developer, you need to face this fact. It's up to you to keep your job enjoyable. It's your responsibility to take care of this. The good news is: yes, you actually can take care of it. I'm not saying that you can mitigate every sort of evilness which might come along your professional life. I'm just saying that you can contribute to experience enjoyable engineering.

Override VIM Settings Per Folder

One nice little feature of good old VI is to allow configuration per folder. Everything you need to do is just place .exrc file in the current folder and kick off VI. This feature still exists with VIM, but is disabled by default. To enable it, just set exrc and VIM will respect custom configurations in current directory as well. VIM recognizes .vimrc files as well, so you're good to go with .vimrc as configuration file name.

Attention: Enabling exrc is dangerous. It is disabled by default for good reason. Since you can do pretty much everything within a VIM configuration file - including shell execution - it's highly recommended to use the exrc option only in pair with a second option which disables shell execution and write operations, called secure. Always append set secure when exrc option is enabled!

Put simply, just append the following lines at the end of your ~/.vimrc:

set exrc
set secure

and you're good to go. Now VIM will recognize and apply your custom project/folder settings. Enjoy.

UserDirs The Fedora Way

First of all, on Fedora 15, you don't edit /etc/httpd/conf/httpd.conf, although you could go for it. Instead, you extend your initial (base) configuration with little configuration snippets located in /etc/httpd/conf.d/. To follow this convention, a simple userdir.conf file in previously mentioned directory should be created with the following content:

<IfModule mod_userdir.c>
    UserDir enabled [user]
    UserDir public_html
</IfModule>

<Directory /home/*/public_html>
    Options Indexes Includes FollowSymLinks

    AllowOverride All
    Allow from all

    Order deny,allow
</Directory>

Note that in above file [user] is a placeholder for the actual user (you might as well extend/change this for your purposes as well). Assuming that /home/[user]/public_html/ exists, one might think that a quick sudo service httpd restart should do it then. No it won't. Navigating to the userdir URI just responds with a cold 403 permission denial.

"Alright", me thinks. It's time to pay attention to SELinux.

Tweaking SELinux Settings

The security configuration of SELinux on Fedora 15 is enabled by default (set to Enforcing). You might go for the easy way and disable SELinux completely. However, instead of breaking a fly on a wheel, I decided to go for the needle-haystack game and adjust SELinux settings.

First of all, ensure that the directories have proper permissions:

## home directory ##
sudo chmod 711 /home/[user]

## public_html directory ##
sudo chown [user]:[user] /home/[user]/public_html
sudo chmod 755 /home/[user]/public_html

Then, tweak SELinux settings for user directories and user content:

sudo setsebool -P httpd_enable_homedirs true
sudo setsebool -P httpd_read_user_content 1

Finally restart httpd. Voilà, c'est ça!

Ein Code Retreat scheint eine super Sache zu sein. Ich würde wirklich sehr gerne an einem Code Retreat teilnehmen, da sich bis jetzt noch nicht die Gelegenheit ergeben hat und ich die Idee des tagesumfänglichen "Retreats" sehr spannend finde. Der Wille ging bei mir sogar soweit, dass ich bereit wäre, den organisatorischen Aufwand auf mich zu nehmen. Aber gerade in den letzten Monaten hat sich dieses Blatt bei mir gewendet.

Dabei habe ich nach wie vor große Lust, ein Code Retreat einmal umzusetzen. Es liegt auch nicht daran, dass ich keine organisatorischen Mittel an der Hand gehabt habe oder ähnliches. Nein, es ist etwas auf den ersten Blick viel profaneres: die Übersättigung.

Ich bin in der letzten Zeit auf einigen Veranstanstaltungen und Events gewesen, größtenteils auf Barcamps oder anderen, community-getriebenen Events. Das ist super, denn eine so große und reichliche Auswahl an gutem (und günstigen) Content gab es meiner Meinung nach noch nie.

Aber ich fühle mich trotzdem übersättigt. Übersättigt von der Anzahl als auch von der Auswahl der Veranstaltungen und Möglichkeiten. Vor Allem in der .NET Community tut sich einiges. Da weiss man durch die Fülle des Angebots schon garnicht mehr, wo man jetzt wann hingehen soll. Gerade dieses Gefühl bringt mich dazu, nun wesentlich selektiver Vorzugehen, wenn es um meinen eigenen Beitrag zur Community geht. Ich bin der Meinung, dass man immer zunächst in seinem eigenen Zimmer aufräumen sollte, um sich dann ein sauberes Haus wünschen zu dürfen.

Den Anfang mache ich für mich selbst durch den Verzicht auf die Organisation eines Code Retreat hier in München.

Vorwort

Ich habe nachgedacht und gezögert, bevor ich jetzt nun wieder einmal über Coding Dojo's schreibe. Für den interessierten Leser sei nochmals kurz auf die Referenzen zu Teil I und Teil II meiner eigenen Meinungsbildung zu Coding Dojo's verwiesen. Nun mag man sich fragen, "muss es ein Teil III geben"? Aber für mich ist es ein wichtiges Thema, über das ich lange gegrübelt habe. Die bisherigen Erkenntnisse daraus halte ich hier einmal fest.

Metapher Coding Dojo

Der ausschlaggebende Grund für meine Gedanken über die Art, Form und Interpretation von Coding Dojo's ist zweifelsohne die Metapher "Dojo". Das Dojo, der Übungsraum, die Kata, die Übung. Ist doch alles einleuchtend, oder?

Nein! Alles Lüge! Das Coding Dojo ist ein Coding Dojo, die Code Kata eine Code Kata. Wenn das Coding Dojo nicht Coding Dojo heissen würde, sondern Coding Disco und die Code Kata nicht Code Kata, sondern Code Foxtrott, was wäre dann eine "Coding Disco"? Wären wir, die Coding Dojo-Gänger und Code Kata-Praktizierer dann alle verrückte Discotänzer?

Für mich steht fest: Das Coding Dojo wie auch die Code Kata haben eine Identität. Es existiert aus einer Intention, aus einer motivierenden Kraft heraus. Die "Metapher" des "Dojo" soll diese Identität unterstreichen und idealerweise auch stärken. Manchmal habe ich das Gefühl, dass die Metapher zum Dojo und Kata ein treffender Vergleich ist. Manchmal ist es aber auch anders. Schade, wie ich finde.

Coding Dojo's ohne TDD ?!?

So passiert es ab und an, dass Coding Dojo's mit "Variationen" umgesetzt werden. Letztes Jahr gab es z.B. Coding Dojo's ohne Coding, es wurden Coding Dojo's ohne TDD abgehalten, Coding Dojo's mit Präsentationsfolien umgesetzt, "Architektur Dojo's" vorgeschlagen. Sogar Coding Dojo Meisterschaften waren einmal im Gespräch. Dieser Einfallsreichtum ist bemerkenswert.

Ich finde das toll. Diversität ist etwas schönes. Doch ich frage mich dabei schon des öfteren, was eine solche Veranstaltung mit einem Coding Dojo zu tun hat. In meinen Augen hat ein Coding Dojo nämlich schon eine gefestigte Identität. Da bedarf es meiner Meinung nach keiner weiteren "Übungsraum-Metapher-Interpretation" oder einer "Weiterentwicklung des Trainingsgedankens".

Coding Dojo Community

Darüber hinaus finde ich es besonders gut, dass sich in letzter Zeit die Community intensiver mit Coding Dojo's auseinandersetzt. Die Coding Dojo's im Raum Düsseldorf werden immer regelmäßiger, in Karlsruhe gibt es endlich auch eine feste Coding Dojo Truppe und viele Unternehmen veranstalten (mehr oder minder regelmäßig) interne Coding Dojo's. Obgleich wir in München schon seit langer Zeit ein etabliertes Coding Dojo haben, sind sogar bei uns neue Community-Projekte wie ein Java Coding Dojo am Start.

Aber auch Coding Dojo's sind vor problematischen Herausforderungen nicht gefeit. So kommt es durchaus vor, dass Entwickler ein Coding Dojo eher als "Spassveranstaltung" betrachten, anstatt es als lockeres Mittel zum Training und Erfahrungsaustausch zu sehen. Dieser Effekt ist vor Allem bei Konferenzen gut zu beobachten.

Darüber hinaus gibt es natürlich auch diejenigen Dojo-Veranstaltungen, die die Popularität eines "Coding-Dojo" nicht ausschliesslich für die Sache, sondern auch für andere Dinge nutzen möchten. Da ist dann von Zeitschriften-Abo's über Freelancer-Anfragen bis hin zu Recruiting-Maßnahmen alles dabei. Das ist ja auch alles schön und gut, so lange es nicht den eigentlichen Sinn des Coding-Dojo's überdeckt und ein gezügeltes Mass an "Sponsoring" nicht überschreitet. Schließlich ist so eine Veranstaltung auch mit einigem an Aufwand (Zeit, Vorbereitung, Räume usw. usf.) verbunden.

Community, Consumity, Commercity

Ich weiss, das man mich mit den vorherigen Sätzen auch missverstehen kann, wenn man mich missverstehen will. Aber es ist nunmal wie bei jeder Community-Veranstaltung: das Gleichgewicht zwischen Community, Consumity und Commercity sollte gewahrt werden. Zur Erläuterung der o.g. Begriffe in diesem Kontext:

• Community = freiwilliges, ehrenamtliches Engagement
• Consumity = passiver, begleitender Konsum
• Commercity = aktiver, profitorientierter Beitrag

Wie schon erwähnt, ist diese "Balance" ein allgemeines Problem und nicht spezifisch für Coding Dojo's. Dennoch: auch allgemeine Schwierigkeiten können Schwierigkeiten bei Coding Dojo's sein.

Eigenkritik

Nun ist es ja so, dass ich selbst an der Entstehung und Bildung der Coding Dojo Community einen kleinen Beitrag geleistet habe. Gerade deswegen kann und will ich mich selbst nicht von der Kritik befreien. Ich habe mit Sicherheit immer nur gutes gemeint, aber eben nicht immer alles gut umgesetzt.

Ich denke, dass da viele Faktoren eine Rolle spielen. Dennoch kann man schon ein paar Kritikpunkte finden. Ein schwieriges Thema ist sicherlich die "Abendveranstaltung Coding Dojo" und die viel zu sehr vernachlässigte Arbeit zu den Hintergründen und Motivationen des Coding Dojo.

Ein weiterer Kritikpunkt kann auch mir persönlich angeheftet werden: Durch meine Art des "Entertaining Engineers" und meiner immer wiederkehrenden Hervorhebung des "lockeren Erfahrungsaustausches" haben viele den Eindruck gewonnen, dass ein Coding Dojo viel mehr mit Entertainment zu tun hat als mit Training. Das ist natürlich komplett falsch.

Coding Dojo Werte & Ziele

Ich glaube, dass die subjektiven, persönlichen Ziele des Einzelnen beim Coding Dojo für die Gemeinschaft auf einen Nenner gebracht werden: Lerne & Lehre. Ich wollte seit dem problematischen Coding Dojo bei den dotnetpro.powerdays diesen Begriff des "Lernen & Lehrens" nicht mehr anwenden, aber es trifft es immer noch ziemlich gut.

Ein Coding Dojo hat zum Ziel, die gemeinschaftliche, respektvolle und praxisorientierte Auseindandersetzung mit modernen Design- & Programmiertechniken wie TDD, Domain-Driven-Design, Pair Programming, Design Patterns und Refactoring durch lockeren Erfahrungsaustausch zu ermöglichen.

Das ist genau das Gegenteil zu dem für mich traurigen Feedback, was ich in den letzten Wochen oft bekommen habe. Ich habe von Neulingen und auch erfahreneren Dojo-Gängern in letzter Zeit immer wieder gehört, dass ein Coding Dojo doch nur ein "nettes Rahmenprogramm" sei oder aber eine etwas bessere "Recruiting-Veranstaltung". Das ist nicht richtig.

Coding Dojo Resources

Ich habe schon vor einiger Zeit zu dem Coding Dojo ein paar Grundlagen und Werte zusammengefasst. Es gibt aber im Netz noch viele weitere informative und hilfreiche Quellen zum Coding Dojo:

• Coding Dojo General Information (english):
  Generelle Informationen zum Coding Dojo, mit Werten und Grundregeln.
• Beschreibung vom Coding Dojo Berlin:
  Eine gute und motivierende Beschreibung des Coding Dojo's
• Single Slide Coding Dojo Description (english):
  Die Fakten eines Coding Dojo auf einem Slide (mit 2 Slides Code-Kata "Data Mungler" Beschreibung)
• What is Coding Dojo?: Eine kurze Beschreibung der Dojo Grundregeln vom Orlando-Dojo
• Ruby Coding Dojo:
  Eine Präsentation über Coding Dojo's von der Ruby Community (DACH), inkl. dem 100-Doors-Problem als Kata
• Coding Dojo Experience (english):
  Ein Bericht über die Lerneffekte des Coding Dojo von Gil Zilberfeld
• Coding Dojo Survey Results (english):
  Ein sehr informativer Artikel über die Lernziele und Lernergebnisse im Coding Dojo vom Emily Bache
• Coding Dojo Learning Environment (english):
  Ein Artikel über die Lernumgebung und -Methoden im Coding Dojo von Danilo Sato

Es gibt im Netz natürlich noch viele weitere Quellen, aber die obige Liste ist meines Erachtens für den Interessierten ein guter Anfang.

Konsequenzen? Konsequenzen.

Aus den oben genannten Überlegungen heraus ergeben sich für mich ein paar persönliche Schlußfolgerungen. So gibt es in der letzten Zeit immer mehr Aktivität von der Community, eigene Coding Dojo's zu machen. Als Beispiele seien hier nur das Coding Dojo in Karlsruhe und das Coding Dojo auf der Seesharp-Party genannt.

Diese Dynamik in der Community ist super und ich kann jeden unterstützen und aufmuntern, selbst ein Coding Dojo zu organisieren oder zu veranstalten. Egal ob in der Firma, in der lokalen Community, oder aber auf einer Veranstaltung. Wenn es eine offene, aufrichtige und ernstgemeinte Auseinandersetzung mit dem Coding Dojo ist, dann ist es gleichermaßen unterhaltsam und wertvoll.

Wenn jedoch dabei das Gleichgewicht von Community, Consumity und Commercity wankt, oder aber das "Dojo" zur HR-Kontaktbörse wird, oder ein Dojo zu einem "Party-Programmpunkt" mutiert, dann finde ich persönlich das nicht besonders wertvoll, sondern eher schade.

Ich glaube weiterhin, dass ich als Person ein Faktor für die Missinterpretation des Coding Dojo's bin. Obgleich bin der Meinung bin, dass fast alle meine Coding Dojo's auf Veranstaltungen gute Coding Dojo's waren, werde ich in der nächsten Zeit keine Coding Dojo's mehr als Operator auf Konferenzen leiten.

Darüber hinaus möchte ich alle Coding Dojo-Gänger - ganz besonders aber die Münchener Dojo-Community - nochmals aufmuntern, weiter das .NET Coding Dojo zu besuchen. Wir in München - besonders Pete, Fuip und Christian - investieren viel Zeit, Aufwand und Stress, um ein gutes Coding Dojo zu veranstalten.

Wenn einem dabei manche Recruiting-Hinweise vom Veranstalter missfallen, dann kann er ja kurz weghören. In keinem Fall sollten "We are hiring"-Rufe dazu verleiten, das Coding Dojo nicht mehr zu besuchen. Pete, Fuip und Christian machen Dojo's des Lernen & Lehrens willen, da könnt ihr euch sicher sein. Und: Ich werde natürlich weiter mit Pete und den anderen das Ziel des Lernens & Lehrens mit dem Coding Dojo verfolgen und stärken.

Abschließend möchte ich noch einen kleinen Hinweis gepaart mit einem Ausblick geben. Wer mir auf Twitter folgt, der wird eventuell schon mitbekommen haben, dass ich gerne einmal ein Code-Retreat mitmachen würde. Ich mag die Idee des Code-Retreats und habe auch schon mal getweetet, dass ich gerne bereit wäre, ein Code-Retreat zu organisieren. Ich habe mich dazu entschlossen, diese Idee nicht weiter zu verfolgen. Ich werde kein Code-Retreat organisieren. Die Gründe werde ich eventuell in einem separaten Blog-Post darlegen.

Statt dessen möchte ich andere Dinge gerne ausprobieren. Wer offen, aufrichtig und ernsthaft daran interessiert ist, der kann sich bei mir gerne via Email oder Xing melden.

Second, if you're willing to give Fedora a spin (or even install it), then I'd strongly recommend you to create a Fedora Live-USB. In my opinion it's so much easier to boot and install from USB compared to CD. Naturally, your system needs to support booting from USB.

Gain Sudo Powers

I'm a fan of sudo. I like it because it explicitly reminds me that I'm crossing the barrier from user to sysop, with all the implications it has. I've been using sudo since SuSE 4/5. Needless to say that obtaining sudo powers is the first thing I do on a fresh system.

In order to gain sudo powers, you simply need to add yourself to wheel group (as root, of course): usermod -G wheel -a [user], whereas [user] is your user name. To immediately apply group membership just fire off grpconv and voilà. Remember: With great power comes great responsibility.

Disable IPv6

IPv6 is cool. However, it's a sad fact that using IPv6 is often a pain. On some networks, it's just fine, on others it terrificly slows down NS lookups and connection speed. Causes range from dual stack issues up to poorly configured routers. In case of a "slow internet connection" you might consider to disable IPv6 support. In order to disable IPv6 on Fedora, perform a few easy steps:

• Add the ipv6 module to the list of blacklisted modules, so that it won't be loaded on system boot. Open the file /etc/modprobe.d/blacklist.conf and append the following line:
  blacklist ipv6
• Make sure the network settings exclude IPv6 support by adding the following line to /etc/sysconfig/network:
  NETWORKING_IPV6=no
• Disable the (now useless) IPv6 firewall by typing
  sudo chkconfig ip6tables off
• If you already have network connections established (either wired or wireless), you disable IPv6 network initialization for those as well. You might do this via Network Manager UI or just change the following line:
  IPV6INIT=yes to IPV6INIT=no in any of your desired connection configuration file, which typically follows the naming convention ifcfg-[ConnectionName] whereas [ConnectionName] is the name of your (wired or wireless) connection configuration. The connection configuration files are located in /etc/sysconfig/network-scripts.

Reboot the machine (just enter reboot) and ensure that everything went fine by typing lsmod | grep ipv6 which should just return nothing.

Stay Up-2-Date

Once internet connection is fast and seamless, the next important thing is to update the system. There's too many reasons why updating the fresh F15 install is a good idea, so just do it.

With yum there's nothing easier than a system update. You can check and review all pending updates with sudo yum check-update. Naturally, installing updates is as easy as sudo yum update.

To finish the essential package housekeeping, adding the RPM Fusion repositories is highly recommended. It'll make life much easier with some crucial installs, like enabling MP3 support.

Adding RPM Fusion package repositories is a one-liner:

sudo yum localinstall --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

For me at least, above three steps are the foundation for a stable and frictionless installation and user experience. Next, I'll cover a few Vaio specific topics. It's not very much to talk about, since out-of-the-box support for Vaio S-Series on Fedora 15 is very good. Nearby, my Vaio is a VPCS12V9E.

GCC FTW

What's at least equally important as an up-to-date system? It's GCC, the Gnu C Compiler. You don't need to be a C/C++ coder in order to need and use it. There's software out there which might not be bundled with Fedora yet. I personally use it quite often to compile software from bleeding edge sources. Hence sudo yum install gcc is indeed a good idea.

Qualcomm Gobi 2000 WWAN Support

Fedora has very good networking support. With qcserial, it basically supports connecting through Qualcomm WWAN devices by default. On other distros, I had to compile qcserial and use gobi_loader to load the Sony Qualcomm firmware files. With Fedora 15, it just got a major step simpler, at least for my special case with Sony Qualcomm Gobi 2000 WWAN module.

As far as I have figured out, Network-Manager on Fedora 15 proactively looks for firmware files on /lib/firmware. The device recognition is triggered by udev rules, residing in /lib/udev/rules.d. After hours on fiddling around how the device recognition and initialization process works, the solution was quite simple at the end.

All I needed to do was to copy the firmware files (UQCN.mbn, amss.mbn and apps.mbn) to /lib/firmware, reboot the system and enjoy wireless mobile networking.

In case you wonder: The 3 abovementioned files are propietary firmware files. You can't download them. Even Sony / Qualcomm as vendors don't provide a download of firmware files. The easiest way to obtain the files is to install the WWAN driver for Windows provided by Sony and pick the necessary files from Windows installation.

Typically, firmware files are located at %ProgramFiles%\QUALCOMM\Sony. You'll find a bunch of numbered folders there alongside with an UMTS folder. You can find amss.mbn and apps.mbn files there. The numbered folders contain mobile tepephony provider specific versions of UQCN.mbn. The version in folder 6 seems to be a generic firmware driver info and works quite well with my provider.

AVI, MP3, MPEG4 and more

Let's face it. You need codecs. Easiest way to support most of the propietary codecs is to install gstreamer ugliness using

sudo yum install gstreamer-plugins-ugly gstreamer-ffmpeg xvidcore

Note that previous line only works if RPM Fusion repositories are available.

Fedora on a Vaio

After all, installing and using Fedora on a Vaio Notebook is a great experience. Almost everything is working out of the box. The nouveau driver for NVIDIA works seamless, all internal devices are being recognized and taken care of by Fedora. Touchpad, camera, fingerprint sensor, and even the sony-specific FN-Keys.

Fedora on a Vaio is great.

We're In The Game Called Open Source

Granted, there's Outercurve with Codeplex. And most recently, we happily observe alot of open source projects in .NET Ecosystem, even from Microsofts "inner circle", like ASP.NET MVC and Nuget. Plus there's plenty of momentum in the .NET Community towards open source projects, especially when it comes to tools and frameworks.

However, for me there's still a strange feeling of discrepancy between "Microsoft" and "Open Source". Now, with the Open Art event in Munich, I had the chance to talk with the chief strategist of Microsoft in person to find answers for this surreal picture of Microsoft's Open Source Initiative.

Open Source Is Important For All Of Us

One of the first (and most obvious) questions I was lucky to ask Mr. Utzschneider was: "Why do you care about open source anyway?". His answer was quite simple: "Why shouldn't we care anyway?"

It's worth to have a look behind the curtains of his short & snappy answer. The open source idea as well as the community has matured and is a vital part of our life. Linux as operating system runs on a gazillion of devices, from coffee-machines up to parking-lot-systems. PHP drives millions of websites, ranging from blogs up to world-changing websites like Wikipedia. That's why Open Source is important for all of us.

Integration

I personally believe that Microsoft realizes the importance of Open Source for our society (and therefore our economy, as well). Apparently, Microsoft is not trying to make significant changes to business models or its identity just for the sake of the Open Source movement. Instead, Microsoft aims to integrate with Open Source.

It's like two families from different cultures now living next to eachother in the same street called "IT Road". At first sight, it seems impossible to be neighbors. Different cultures, different traditions, different languages.

However, as time forces both to live and see each other, a common understanding of "live and let live" is established. The next step is being a respectful, polite, friendly and aiding neighbor for each other. That's the stage Microsoft is aiming with Open Source right now.

Intellectual Things

However, it's not all shiny weather at "IT Road". One of the biggest topics we're facing with the open source debate these days is intellectual property (in short, IP). IP is a key factor for success in software development economy.

For propietary software, the situation is quite clear. The message is really simple: "I invented it, I made it, I sell it. It's mine." No idealism, just capitalism. Straight forward.

For Open Source, it's by far more complicated. Just have a look at what licensing possibilities you have if you're willing to publish and share your sources.

Once you're through the jungle of licenses, you're ready to share your source. Let's say your software is a blast and is being used day by day by thousands of users. Thousands of users have thousands of different tasks, thousands of different ideas and wishes. The level of support & maintenance for a successful Open Source project is not to be underestimated, IMHO.

Mixed Feelings: Freemium

Ok, support and maintenance of a large user base and/or project actually is considerable effort. That's one of the main reasons why there's a business model called Freemium. Freemium is sort of an hybrid vehicle in software landscape. It delivers value to both the free and premium user base. While basic, limited functionality is available for free, advanced or high volume features need to be payed for.

In Open Source world, Freemium can both vitalize and poison. I think it's the dose making Freemium a win/loose model.

You need money to continue delivering value for free, that's a fact. However, once the part of "money making" becomes more and more important, Open Source is kind of lost at sea. Take the recent developments around Mono as a living example.

The Definition Of Open Source

What's Open Source then? Is Mono, ASP.NET MVC or Nuget really Open Source? From an idealistic perspective, a clear definition of Open Source is needed. According to OSI, Open Source needs to be:

• freely distributable,
• source code included,
• derivable,
• attributed to author,
• non-discriminating,
• license-keeping,
• neutralized to product or platform.

You decide.

Nonetheless, I personally think that the "definition" of Open Source is not only restricted to materials or intellectual property. To me, Open Source has a bold cultural aspect as well. I won't dig into details here because I know this topic is epic. Maybe I'll have the chance to blog about my own perspective of the culture of Open Source in future. Nonetheless, Microsoft, IBM, Mozilla, Apple, Google and whatever great software vendors you know - I think all are aware of the fact that there's more to Open Source than just "Open Source".

The Next Level

I want to get back to my impressions of the Open Art Event and Mr. Utzschneider. In his speech, Mr. Utzschneider mentioned that he's glad to see that we as software developers and digital enthusiasts have the chance to create great things. Everybody should be free to create, share and use the things he's interested in.

Mr. Utzschneider continued by telling us that it's a good thing to see Microsoft employees using IPads and MacBook users to see using Windows 7. He continued to describe that software is about enabling possibilies and opening minds:

"Software is not only Function, it's Art as well. Creating great things is a creative, artful task. I'm from Seattle, and as many of you might know, Seattle is popular for great Music. Seattle is the Home of great artists like Jimi Hendrix, Nirvana and many more. Especially the Jazz culture is vital and bright.

I really love music. In my precious spare moments, I support a local Seattle project called KEXP. It once was a radio station, now it's a project supporting various local artists and newcomers. The platform broadcasts hundreds of concerts a year with all those great artists. At KEXP, it's the artist and his art being in focus. For example, some artists may choose to provide their songs for free while others may want to have a small amount of monetary compensation for all the hard work and efforts. And that's ok.

The key point here is that everything is possible. You're not forced to give away everything for free. And of course you don't need to go commercial to gain audience and respect. The major benefit and joy is, in fact, being open-minded in an open-minded society."

Open Source And Open Minds

I honestly need to admit it: Mr. Utzschneiders speech left me impressed and inspired me to think over this whole Open Source and Open Minds topic. I truly believe that we as software developers as well as software consumers need to realize and accept that all colors are beautiful.

It's not Microsoft producing the best software products in the world. It's not Linux being the best operating system in the world. It's not Google providing the best mobile experience in the world. It's not Apple changing everything, again and again.

It's you to do and use what is best for you.

What I have learnt from this Open Art Event and Mr. Utzschneider is that being Open Minded is not easy. However, being Open Minded is the key for us to open others minds, hearts, creativity and emotions.

That's what we should do with software. That's what I do with software.

Be Open Minded.

Famstag, fer 21. Fai 2011, fein fanz formaler Famstag, fin Fürnberg, fim fönen Franken. Fis fauf feine Fausnahme: Füberall fein F!

Der .NET Day Franken 2011

Samstag morgens habe ich mich nach ein paar Tagen (notwendiger) Erholung aufgerafft, mich mit Sebastian zum .NET Day Franken 2011 zu begeben. Meine Erwartungshaltung war groß, denn ich hatte im Vorfeld schon viel positives über die Fränkische Community Konferenz gehört.

F wie Freundlich

Trotz eines kleinen Malheurs konnten wir den Veranstaltungsort in Nürnberg gut erreichen. Raus aus dem Auto und rein in die Konferenz war unsere erste Devise. Kaum in den Räumen angekommen, bekamen wir von überall ein Lächeln geschenkt.

Am Empfang lächelten die Damen und gaben uns zügig die notwendigen Materialien und Info's. Im Sprecherzimmer lächelten ein gelassener Tom und Bernd, trotz des Konferenz-Trubels. Die Teilnehmer freuten sich auf regen Austausch und die Vorträge. Fazit: You got an F! (like "Freundlich").

F wie Frei

Erstaunlich fand ich persönlich, wie frei und locker die Konferenz-Atmosphäre war. Diese (wohl sehr fränkische) Gelassenheit wurde aber vor allem durch die Kombination von guter Location, guter Raumorganisation und guter Konferenzgröße (ca. 150 Teilnehmer) ermöglicht. Es wurde niemals zu eng, zu heiß oder zu unpersönlich. Man konnte sich zu Einzelgesprächen zurückziehen (z.B. auf der Terasse) oder aber sich in Gruppen unterhalten können. Fazit: You got an F! (like "Frei").

F wie Feinschmecker

Die Verpflegung auf der Konferenz war einsame Spitze. Das Catering war auf den Punkt immer da, das Buffet und die Getränke reichhaltig vorhanden. Die kleinen Snacks zwischendurch waren super, der Kaffee hat richtig gut geschmeckt und das Mittagessen war in nicht nur sehr schmackhaft, sondern auch sehr geschmackvoll.

Ein besonderer Pluspunkt war meines Erachtens die angenehme Umgebung. Jeder konnte angenehm am Tisch nicht nur speisen sondern auch wertvolle Tischgespräche führen. Fazit: You got an F! (like "Feinschmecker").

F wie Fachwissen

Neben meiner Session zu einigen, wenigen XP Secrets hatte ich auch das Vergnügen, bei zwei weiteren Sessions dabei zu sein. Meine erste Session: "Gelebtes Scrum" von Christine Strattner. Ein solider Überblick über die Methode, gepaart mit ein paar kleinen Anekdoten aus der Praxis. Für den Newcomer sicherlich ein wertvoller Vortrag.

Nach meinem eigenen Vortrag verschlug es mich zu "Find your Flow with TPL" von Sebastian Achatz. Er hat es verstanden, innerhalb von 70 Minuten die Konzepte und Wirkungsweisen der Task Parallel Library so zu vermitteln, dass man danach schon mit juckenden Fingern wieder an der Tastatur kleben wollte, um selbst die bemerkenswerte TPL auszuprobieren und einzusetzen.

Schade, dass ich für die anderen hervorragenden Sprecher und Vorträge keine Zeit aufbringen konnte. Nichtsdestotrotz- oder besser gerade eben deswegen - ein klares Fazit: You got an F! (like "Fachwissen").

F wie Fantastisch

Abschliessend möchte ich meinen persönlichen Eindruck widergeben. Ich hatte schon eine "gesteigerte" Erwartung an die Konferenz - auch wegen der vielen Stimmen, die mir die Konferenz empfohlen haben. Trotzdem hat mich dieser .NET Day Franken doch ziemlich überrascht.

Für mich ist die Konferenz ".NET Day Franken" eine hochwertige und anspruchsvolle Veranstaltung in jeder Hinsicht: Themen, Vorträge, Ort, Verpflegung, Organisation, Rahmen. Das Preis-Leistungs-Verhältnis ist nicht nur fair, sondern auch ein absoluter Knaller für diese ganzheitliche Premium-Qualität, die der .NET Day Franken bietet. Fazit: You got an F! (like "Fantastisch").

F wie Fakt

Meine Meinung in einem Satz: Der .NET Day Franken ist das non plus ultra, wenn es um eine .NET-Konferenz in Süddeutschland geht.

Es gibt keine vergleichbare mir bekannte Konferenz, die in allen Punkten ein derartiges Erste-Bundesliga-Niveau bietet. Das ist kein Honig-ums-Maul-Geschmiere, sondern ein ganz klares und deutliches "F". Fazit: You got an F! (like "Fakt").

F wie Franken

Mit einem siebten "F wie Franken" möchte ich meine Eindrücke abschließen. Dieses siebte F steht für Franken als Region sowie als Gesellschaft. Ich habe Franken als gelassene Profis erlebt, die auch gerne über sich und andere scherzen, dabei aber nie den Respekt und den angenehmen Umgang aus den Augen lassen. Der .NET Day Franken hat vergleichbare (kommerzielle) Konferenzformate nicht nur in den Schatten gestellt, sondern mit einem "You got an F!"-Gruß regelrecht "platt gemacht".

Fazit: You got an F!

("... representing Deutschland, yea!") ;-)

Es kam jedoch anders. Meine Erwartungen wurden nicht erfüllt. Nein, sie wurden sogar getoppt. Die diesjährige DotNet Cologne war für mich eine professionell organisierte Veranstaltung, bei der es viele interessante Themen und Gespräche zu erleben gab.

Besonders gefallen hat mir die lockere Konferenzatmosphäre. Ich hatte das Glück, gleich zu Beginn meine Session über Agile Architekturen halten zu dürfen. Dadurch konnte ich mich "entspannt" den weiteren Sessions von Daniel Fisher, Bart de Smet und Tim Fischer widmen.

Ohne den Inhalt und den Wert der Sessions schmälern zu wollen möchte ich allerdings die wertvolle Zeit zwischen den Sessions hervorheben. Die Veranstalter haben mit der 30 Min. Session-Pause eine sehr gute Entscheidung für rege Community-Gespräche und Entwickler-Austausch getroffen. Dadurch war ich in der Lage, mich mit vielen interessanten Entwicklern und Meinungen austauschen zu können.

Offen gesagt: Die Zeit hat trotzdem nicht gereicht. Gerne hätte ich mich noch intensiver über verschiedene Themen ausgetauscht (Codename: "Pinocchio") und noch näher neue Bekanntschaften kennengelernt (Codename: "Twitterlabel"). Alles in Allem kann ich nur sagen: die DotNet Cologne ist eine Konferenz, die nicht nur neue Aspekte und Denkanstöße für aktuelle Entwicklungs-Themen liefert, sondern im wahrsten Sinne eine Plattform zum Austausch für die .NET Gemeinde in Deutschland bietet. Das alles von der Community, für die Community.

Eine bewundernswerte Glanzleistung der Organisatoren Albert, Roland und Stefan. Bei der Größe, der Professionalität, dem Preis und der Leistung dieser Community-Konferenz ist es förmlich das Mindeste, auch mein deutliches und dickes Danke den Sponsoren der Konferenz zu sagen. Es ist gerade die gute Mischung aus engagierten Unternehmen und engagierten Entwicklern, die Geld, Zeit und Arbeit investieren, um solche Veranstaltungen für mich und die gesamte .NET Community zu ermöglichen.

Mein Fazit: Teilnehmen bei der DotNet-Cologne 2012!

Es gibt in München sehenswürdiges. Manchmal gibt es in München auch merkwürdiges. Ab und an gibt es in München auch denkwürdiges. Seit kurzem gibt es für den Agile lebenden und Lean denkenden Münchener eine weitere denkwürdige Sache: Das ALE Network Munich.

Was ist ALE?

In kurzen Worten: ALE steht für Agile Lean Europe und ist eine von Jurgen Appelo ins Leben gerufene Initiative für den offenen Austausch und konstruktive Zusammenführung agiler Köpfe in Europa. Diesem Aufruf von Jurgen sind in ganz Europa viele Agilisten gefolgt, darunter auch einige Agile & Lean Enthusiasten in Deutschland.

Mit der Koordinations- und Organisationsunterstützung von Olaf Lewitz haben wir für Deutschland auch einen "Repräsentanten", der uns im internationalen Austausch von Ideen, Erfahrungen und Konzepten innerhalb des ALE Networks vertritt. Das ALE Network sieht sich in erster Linie als eine nicht-kommerzielle, offen kultivierte, fortschrittsgewandte Interessensgemeinschaft von Agilisten und Lean Denkern in ganz Europa. Wir in München sind ein Teil dieser Gemeinschaft und freuen uns, mit optimistischer und offener Partizipation im ALE Network dabei zu sein.

Wieso ALE?

Aber wieso gibt es das ALE? "Nicht schon wieder eine weitere Agile Community..." wird sich manch Einer denken. Doch weit gefehlt, ein genauerer Blick auf ALE enthüllt Motivation und Antrieb. ALE ist aus der Idee entstanden, dem globalen Austausch von agilen Themen eine lokale - ja, eine europäische - Dimension zu geben. ALE hat das Selbstverständnis des unabhängigen, unkontrollierten, unverbindlichen Erfahrungsaustausches unter Agilisten. ALE strebt nicht nach Organisation, Hierarchie oder Kommerzialisierung. Insofern sollte ALE nicht als Institution, Organisation oder "Yet another agile community" betrachtet werden.

ALE bezieht ihren Antrieb als ein offenes, kulturelles und informelles Netz von vielschichtigen, fortschrittsgewandten, veränderungstreibenden Menschen - den Agilisten & Lean Denkern.

München und ALE

Mit dem Aufruf von Jurgen und Olaf, hier in Deutschland, das kommende ALE Gathering bei den XP Days in Madrid mit Werten und Ideen aus ganz Europa zu bereichern, haben Christian, Wolfgang und ich uns angesprochen gefühlt, nicht nur unseren Beitrag durch Wertevermittlung und aktiver Teilnahme zu leisten, sondern darüber hinaus das Münchener Fenster für die europaweite, "Agile & Lean-Frischluft" zu öffnen.

Nach einem langen gestrigen Abend haben wir uns entschlossen, der grossen Münchener Gemeinschaft der Agilisten und Lean-Befürworter einen offenen und ungezwungenen Zugang zur europaweiten ALE Community zu verschaffen. Wir glauben fest daran, dass die Symbiose von europaweiter Verknüpfung und lokaler Kultivierung ein tragfähiges Fundament für die Weiterentwicklung der agilen Werte und Prinzipien als auch der schlanken Methoden und Verfahrensweisen ist. Für uns heisst das: das ALE Network hat in München mit all seinen professionellen Agilisten und Lean-Vordenkern ein lebhaften, offenen, aktiven und wertschätzenden Knoten im europaweiten Netz.

Du und 3 Worte: Agile, Lean, Europe

Wir - also Christian, Wolfgang und ich - möchten Dich und Deine agile Expertise, Deine schlanken Verfahren, Deine neuen Ideen mit Gleichgesinnten in Europa näher bringen. Lokal, Verbal, Viral. Deshalb rufen wir auf zum ersten ALE Network Treffen in München, am Di, den 03. Mai 2011 um 20:00 Uhr, in der Niederlassung in München. Sei dabei und lass uns gemeinsam über unsere individuellen Ideen und Wege zum ALE diskutieren! Für die Anmeldung reicht ein Kommentar auf diesem Blog-Post oder eine Anmeldung beim Xing-Event.

Wir freuen uns auf Dich und einen erkenntnisreichen Abend!

A brief english summary:

We, that is Christian, Wolfgang and me, have received a call for participation in ALE Network by Jurgen Appelo. Amplified and initiated by Olaf Lewitz, we had a long brainstorming session yesterday on what ideas, thoughts and values we can contribute to the overall ALE initiative. With the ALE Gathering session at XPdays in Madrid right in front of our door, we want to engage our local community of agile practitioners and lean thinkers here in Munich to bring in an individual, diverse perspective to the european Agile & Lean network.

We strongly believe that the synergy of global connection and local cultivation is a solid ground for a thoughtful progress to an improved adoption of agile values and lean methodologies.

This belief is our motivation to call agile & lean practitioners in Munich to a first meetup for the "ALE Network Munich", an event for open discussion and exchange of thoughts for the ALE network initiative. Join us on Tue, 3rd May at Niederlassung in Munich! Let's get in touch with Agile & Lean minds all over Europe!

An Enigma for products

Example Product Codes: A1, B52, D2, X404

The "department source qualifier" (aka DSQ)
|
v
B52
 ^^
  |
  The product number (aka PN)

Moreover, you have two separate lists of product codes at hand. The first list is from your CEO, while the second list origins from internal controlling department. Obviously, both lists are different. It's not only that one list contains product codes the other does not have, but as well that both lists seem to have different product numbering schemes.

Make your CEO happy

You have been assigned by your CEO to complete the following task: Pick all "akin" products by examining their DSQ. If both lists contain product codes of same DSQ, remove them from original list and copy them over to a new "Akin"-List. Leave the remaining product codes as is.

The following two lists:

ceoList = [A1,B1,A2,A3,C1,D1,E1,E2]
controlList = [F1,D2,B2,B3,A4]

Results in following "Akin List" with modified CEO and control lists:

akinList = [A1,B2,A2,A3,B3,A4,D1,D2,B1]
ceoList = [C1,E1,E2]
controlList = [F1]

(Note: The order is not relevant)

Be smart

Let's put it straight: Write a program that takes two lists (ceoList and controlList) containing an arbitrary set of product codes in the above described format. The program produces three lists. The first list is the akinList, that is, the list of all akin products taken from the input lists. The remaining two lists are the reduced ceoList and controlList, respectively.

About

The kata stems from a real life scenario. Actually, I did not invent the kata, all credits go to its original inventor, Dr.M. What I did is just to take the essence of the problem and rephrase it a little bit with a story. That's it.

The objective of this kata is to sharpen design skills for trivial algorithms. Dr.M originally posted the problem alongside with a requirement of maximum time complexity O(n^2). A secondary requirement for the solution algorithm is terseness and expressiveness. The more elegant your algorithm is (with respect to the time complexity), the "better". Although it should be paid attention to both non-functional requirements, they're just a "nice to have".

Dann gab es noch das tolle Coding Dojo in Nürnberg bei der DNUG Franken. Ich empfand dabei von Anfang an eine besonders lockere und angenehme Atmosphäre, die meines Erachtens dem Coding Dojo einen sehr konstruktiven Schub gab. Als weitere Besonderheit sollte nicht unerwähnt bleiben, dass viele Teilnehmer den "Erstkontakt" mit einem Coding Dojo hatten und neben einigen Erfahrenen auch ein paar Einsteiger sich dem Thema TDD/BDD widmeten. Es wurden zwei Gruppen gebildet, die sich dann der Kata FizzBuzz angenommen haben. Meiner Meinung nach ist FizzBuzz eine gute Einsteiger-Kata, bei der drei grundlegende Prinzipien des TDD relativ deutlich werden.

An dieser Stelle möchte ich garnicht weiter auf die beachtenswerten Lösungen der "Dodnedder" aus Franken eingehen, sondern eine meiner eigenen Implementierungen von FizzBuzz vorstellen. Wer FizzBuzz schon ein paar mal implementiert hat, der wird vielleicht auch wissen, dass es mehrere (leicht unterschiedliche) Lösungsvarianten gibt. Die Lösung, die ich hier vorstelle ist einer meiner persönlichen Favoriten, weil es vielen Einsteigern (und manchen Fortgeschrittenen) ein Stirnrunzeln entlockt.

FizzBuzz.cs:

using System;
using System.Collections.Generic;

namespace KataFizzBuzz {
  public class FizzBuzz {
    public string Translate(int number) {
      if (number % 15 == 0)
        return "FizzBuzz";

      if (number % 5 == 0)
        return "Buzz";

      if (number % 3 == 0)
        return "Fizz";

      return number.ToString();
    }

    public Dictionary<int, string> TranslateRange(int from, int to) {
      Dictionary<int, string> translations = new Dictionary<int, string>();

      for (int i = from; i <= to; i++)
        translations.Add(i, this.Translate(i));

      return translations;
    }
  }
}

FizzBuzzTranslateTests.cs:

using System;
using NUnit.Framework;

namespace KataFizzBuzz {
  [TestFixture]
  public class FizzBuzzTranslateTests {
    [Test]
    public void Multiples_Of_Three_Returns_Fizz() {
      FizzBuzz fizzbuzz = new FizzBuzz();
      string translation = fizzbuzz.Translate(6);

      Assert.That(translation, Is.EqualTo("Fizz"));
    }

    [Test]
    public void Multiples_Of_Five_Returns_Buzz() {
      FizzBuzz fizzbuzz = new FizzBuzz();
      string translation = fizzbuzz.Translate(10);

      Assert.That(translation, Is.EqualTo("Buzz"));
    }

    [Test]
    public void Multiples_Of_Three_And_Five_Returns_FizzBuzz() {
      FizzBuzz fizzbuzz = new FizzBuzz();
      string translation = fizzbuzz.Translate(15);

      Assert.That(translation, Is.EqualTo("FizzBuzz"));
    }

    [Test]
    public void No_Multiples_Of_Three_Or_Five_Returns_Number() {
      FizzBuzz fizzbuzz = new FizzBuzz();
      string translation = fizzbuzz.Translate(7);

      Assert.That(translation, Is.EqualTo("7"));
    }
  }
}

FizzBuzzTranslateRangeTests.cs:

using System;
using System.Collections.Generic;
using NUnit.Framework;

namespace KataFizzBuzz {
  [TestFixture]
  public class FizzBuzzTranslateRangeTests {
    [Test]
    public void Range_From_1_To_100_Returns_100_Elements() {
      FizzBuzz fizzbuzz = new FizzBuzz();
      Dictionary<int, string> translations = fizzbuzz.TranslateRange(1, 100);

      Assert.That(translations, Has.Count.EqualTo(100));
    }

    [Test]
    public void Returns_Elements_Whose_Values_Match_The_Translation_Of_Their_Corresponding_Keys() {
      FizzBuzz fizzbuzz = new FizzBuzz();
      Dictionary<int, string> translations = fizzbuzz.TranslateRange(1, 15);

      foreach (var translation in translations)
          Assert.That(translation.Value, Is.EqualTo(fizzbuzz.Translate(translation.Key)));
    }
  }
}

Das interessante an dieser Lösungsvariante ist die Zwiespältigkeit. Meiner Meinung nach ist die Lösung

• zwar ausreichend, aber nicht vollständig,
• sie ist stark genug, aber mit Schwachpunkten,
• sie beginnt schnell, aber endet langsamer,
• sie ist offensichtlich, aber dennoch diskutabel.

Genau das ist es, was ich gerade an dieser Lösungsvariante von FizzBuzz mag.

Genau dieser Erfahrungsschatz ist es auch, der mich zur nächsten Aussage förmlich zwingt: Der TFS ist eine Klasse für sich. Man könnte auch sagen, der TFS ist konkurrenzlos. Denn für mich ist TFS eine behäbige, alte Dampflokomotive, die nur mit viel Kohle, starken Heizern und einem idealistischen Lokführer in Gang zu bringen ist. Von der Geschwindigkeit und Zuglast der TFS-Dampflok möchte ich garnicht erst reden.

TFS ist eine feste Marktgröße

Dennoch ist es Fakt, dass der TFS eine feste Position im Markt einnimmt. Man mag jetzt alle möglichen Gründe für diesen Umstand anführen. Ich persönlich denke dass einer der Hauptgründe für den (relativ) breiten Markteinsatz von TFS schlicht und einfach die Bequemlichkeit des Unternehmens (also TFS-Kunden) ist. Wie dem auch sei, der TFS ist da. Ich finde das auch gut so. Jedem das seine.

Sowie vor dem Hintergrund der Präsenz von TFS als auch aus Eigeninteresse ist es für mich dennoch interessant zu wissen, ob und wie sich TFS 2010 mit meinem Toolset anwenden lässt. Jürgen hatte ja schon über die Nachteile von TFS TeamBuild gebloggt. Dem kann ich mich widerspruchsfrei und vollends anschließen. Er merkte z.B. an, dass Team Build sehr schwer mit alternativen Test-Frameworks in Gang zu bringen ist. Richtig - aber es geht. Ich möchte das einmal für MSpec (die Machine.Specifications) vorstellen.

MSpec & TFS: Die Schöne und das Biest

Es gibt einen exzellenten Blog-Post von DoD über den Einsatz von MSpec mit dem TFS 2010 Team Build. Auf Basis dieses Blog-Posts habe ich es auch geschafft, den MSpec-Runner in den Team Build zu integrieren.

Zunächst einmal ist es notwendig, sich die einzelnen Komponenten, also das MSpecBuildTemplate-XAML und den angepassten NUnitTFS-Code zu besorgen (am Ende des Blog-Posts von DoD). Der nächste Schritt ist es, den NUnitTFS-Code zu kompilieren und gleichzeitig die MSpecToMSTest.xslt Datei auf den Build-Server zu verfrachten. Achtung: MSpecToMSTest.xslt ist im Source-Code vom gepatchten NUnitTFS begraben (im "NUnitTFS\Tfs2010" Ordner).

Ich persönlich finde weder den Code noch die Patch-Praxis von DoD schön. Dazu kommt auch noch die zweifelhafte Idee, die XSLT-Templates für die Test-Results-Konvertierung als eingebettete Ressource einzukompilieren. Nun, da ich persönlich diese Lösung sowieso nicht einsetzen werde, überlasse ich das Feld der Optimierungs-Potenziale dem interessierten Leser.

Der nächste Schritt ist es, MSpec mit auf den Buildserver für die Ausführung der Tests zu packen. Für die Testzwecke habe ich beides (also MSpec und NUnitTFS) separat auf den Buildserver gelegt. Bei einem echten Projekt würde ich beide Tools mit in die Versionsverwaltung einbringen.

Sind die Tools erst einmal vorbereitet, kann man endlich zur Tat schreiten und das BuildTemplate im TFS installieren. Bequem in Visual Studio, so wie es sich gehört. Nach dem man das Template zu den BuildProcessTemplates hinzugefügt hat, kann man es auch über die Build Config auswählen. Die Einstellungen sind relativ schnell und einfach gepflegt. Wichtig ist dabei nicht nur da korrekte setzen der Tool-Pfade, sondern auch die Angabe der Buildkonfiguration (z.B. Any CPU|Debug).

Ok. Team Build kann auch anders.

Was kann man nun aus diesem kleinen Experiment mitnehmen? Ja ganz einfach: Team Build kann auch ohne MSTest. Man muss eventuell ein wenig Überzeugungsarbeit hineininvestieren, aber es geht. Im Übrigen ist es auch interessant zu wissen, dass es nicht nur ein angepasstes XAML-BuildTemplate für MSpec gibt, sondern auch für XUnit und natürlich NUnit, denn schließlich ist der Name des auf Codeplex gehosteten Tools nicht umsonst NUnitTFS.

Fazit: Team Build kann auch anders. Aha. Gut - interessant zu wissen. Schönen Dank auch.

Before I continue on my little post about Unit Tests and their test context, let me just be one thing very clear: A handful of unit test frameworks out there have dozens of other approaches for complex context setup. The one I'm going to blog about right now is just one out of those. The following context composition method is rare to be found, because it has some obvious downsides. More about the pros and cons later, let's just start.

With TDD, BDD and Unit Testing in general you always need to set the stage of your test. That is, you need to establish a test context, where you prepare your environment and all involved parties for your system under test. Basically it's the first A (= Arrange) of the AAA-Rule. Now that's nothing new.

In everyday testing, contexts can get fairly complex. Although I personally consider a complex (or large) context to be a smell, it's sometimes unavoidable. One practical application of large and complex contexts is the dissection of a brownfield. Once you're faced with a large context, your test/spec will be bloated by contextual setup.

As mentioned before, some frameworks have very smart tooling and concepts to help you minimize the context clutter. I'll post a separate blog about one of my favorites, the MSpec and MFakes bundle. But this is a story of its own, so we just disregard them for a minute. By the way: in some organizations you might not be even able to just change the testing framework of your choice and need to get along with what you have been provided.

Context is super !?!

As for "traditional" frameworks like NUnit or XUnit (me likes both of them), the Setup method, constructor or whatever initialization method contains the context complexity to its full extent. Hence, your test fixtures will grow in size and complexity. Undesirable.

A very common solution to this is to refactor out context code to an abstract base "context" class. Although most developers do this primarily for readability purposes, the base class is created to favor reuse as well. Which is an illusion, actually. Once following that path, you quickly find your self back in bewildered inheritance hierarchies of "BaseContextClasses". The tests themselves get more and more obfuscated.

Let's examine. A typical base context class might look like this:

[TestFixture]
public abstract class With_CashMachine_Having_100Dollars {

  [TestFixtureSetUp]
  public void Setup() {
    CashMachine = MockRepository.DynamicMock();
    CashMachine
      .Stub(m => m.CheckBalance())
      .Return(100.Dollar());
  }

  protected ICashMashine CashMachine { get; set; }
}

With the above "context base class", a BDD-style test reads quite expressive:

[TestFixture]
public class When_ATM_Checkout_Request_With_200Dollar_Is_Performed
  : With_CashMachine_Having_100Dollar {

  [Test]
  public void Then_Checkout_Should_Fail_With_CashMashine_Failure() {
    var atm = new ATM(CashMashine);
    var checkoutResult = atm.Checkout(200.Dollar());
    Assert.That(checkoutResult.Failure, Is.EqualTo(FailureCode.CashMashine));
  }
}

Bold Backgrounds

Now, the above ATM example is good to serve as fictional example. Nonetheless, reality is complex. Sometimes, it is by far more complex than the above glorified ATM. In every-day use-case-scenarios, a broad set of dependecies play a note in the overall context orchestra. That is, why test context bases start to become a difficult task.

What if the ATM does not only respect the CashMachine, but as well User, Location, Configuration and Time for this particular scenario? How can we construct this broad set of contextual dependencies while keeping up a high readability and maintainability for the tests/specs? A typical approach is to create "the super-context":

[TestFixture]
public abstract class With_CashMashine_In_Europe_By_Night_Using_Strict_Policies_Having_100Dollar {

  [TestFixtureSetUp]
  public void Setup() {
    CashMachine = MockRepository.DynamicMock();
    CashMachine
      .Stub(m => m.CheckBalance())
      .Return(100.Dollar());

    Location = MockRepository.DynamicMock();
    Location
      .Stub(m => m.Area)
      .Return(ATMDistributionArea.Europe);

    /* aso. aso. ... 
     * you get the picture, huh? 
     **/    
  }

  protected ICashMashine CashMachine { get; set; }
  protected IATMLocation Location { get; set; }
  /* ... */
}

A fair thing, isn't it? Well, apparently the context name (class name) is long. And it's too specific. Whenever one of my contextual members change, the context changes as well. Consequently, a new super-base-context and redundant code for context establishment is required.

Ok. Naturally, there's room for improvement. Obviously, parameterization of values would be a plus. So, let's refactor the values out of the context class:

[TestFixture]
public abstract class With_CashMashine_And_Location_And_DayTime_And_Config {

  [TestFixtureSetUp]
  public void Setup() {
    CashMachine = MockRepository.DynamicMock();

    Location = MockRepository.DynamicMock();
    Location
      .Stub(m => m.Area)
      .Return(ATMDistributionArea.Europe);
  }

  protected ICashMashine GetCashMachine(int balance) {
    CashMashine.BackToRecord();
    CashMachine
      .Stub(m => m.CheckBalance())
      .Return(balance.Dollar());
    CashMashine.Replay();
  }

  protected IATMLocation GetLocation(ATMDistributionArea area) {
    Location.BackToRecord();
    Location
      .Stub(m => m.Area)
      .Return(area);
    Location.Replay();
  }

  /* etc. ... etc. ... */
}

Parameterization relaxes contextual strictness while giving back flexibility (and responsibility) to the fixture class. Granted, it might sound a bit picky. It is however a big difference when your test suite is large. With the parametrized context base class from above, a fixture might look like this one: