Innovation, Festpreise und Verantwortung bei Airbus

Vor kurzem habe ich ein interessantes Interview mit Airbus-Chef Thomas Enders über die Probleme mit dem Airbus A400M gelesen.

Zwei Stellen in dem Interview finde ich besonders interessant:

Frage: “Plädieren Sie für eine neue Preisformel bei Rüstungsaufträgen?”
Enders: “Ich plädiere für mehr Ehrlichkeit und Offenheit von Anfang an. Festpreisverträge machen nur dort Sinn, wo die Entwicklungsrisiken begrenzt sind und die Industrie auf vorhandenen Produkten aufbauen kann. Sie sind nicht vertretbar, wenn es um komplette Neuentwicklungen geht wie bei der A400M. […]”
Der Mann plädiert für agile Vorgehensweisen, oder? Schön, dass solche Erkenntnisse auch langsam in die Bereiche der V-Modell-Hardliner vordringen.

An anderer Stelle allerdings:

Frage: “2003 hat Airbus vertraglich einen Fixpreis von 20 Mrd. Euro vereinbart. Nun soll das A400M-Programm 32 Mrd. Euro kosten. Warum ist ein unterschriebener Vertrag nicht mehr bindend?”
Enders: “Es ist richtig, dass die Industrie vor sieben Jahren Dinge versprochen hat, die, wie wir heute wissen, nicht realistisch waren. […]”
Das sieht dann wieder nicht so aus, als meinte er es wirklich ernst. Wer ist denn “die Industrie”? Airbus, oder? Warum sagt er das nicht und übernimmt damit Verantwortung?

Drucken unter Ubuntu mit Turbo-Print

Mit dem Wechsel auf Ubuntu 9.10 sind einige Standard-Pakete weggefallen oder umbenannt worden, die der Canon-Druckertreiber für den Canon MP-620 benötigt. Zumindest direkt nach der Freigabe von 9.10 war von Canon auch noch kein Update des Druckertreibers verfügbar.
Da bin ich auf Turbo-Print gestoßen. Turbo-Print unterstützt alle mögliche Drucker (darunter auch den Canon MP-620) und ist im Gegensatz zu den Canon-Ubuntu-Treibern auch ganz einfach zu installieren.
Einziger Wehrmutstropfen ist, dass Turbo-Print kommerziell ist – knapp 30 EUR ist jetzt aber auch nicht so viel Geld.
Und mit Turbo-Print klappt’s jetzt auch wieder mit dem Drucken.

Wieviel Schutz brauchen Entwickler?

Vor ein paar Tagen habe ich mit einem Web-Entwickler gesprochen, den ich sehr schätze – über Java-Script. Wir waren uns schnell einig, dass Java-Script stark unterschätzt wird.

Und dann habe ich ihn etwas ausgefragt, um mich selbst weiterzubilden. Mir ist z.B. notorisch unklar, ob es einen einheitlichen Stand der Kunst zur Definition von Klassen in Java-Script gibt. Und in dieser Diskussion sind wir auch auf private Felder und Methoden in Klassen gekommen. In Java-Script kann man beides machen, es sieht aber nicht so übersichtlich aus.

Daher macht mein Gesprächspartner das gar nicht und markiert Privates einfach mit einem führenden Unterstrich. Und das funktioniert nach seinen Aussagen auch sehr gut. Und zusätzlich muss man sich beim Unittesten nicht damit rumärgern, dass man an irgendwas nicht drankommt.

Und tatsächlich: Wenn ich an 12 Jahre Java-Entwicklung zurückdenke, habe ich kaum von privaten Methoden profitiert. Aber behindert haben sie mich ständig.

Ähnlich verhält es sich mit Konstanten. Klar muss man wissen, was konstant ist. Aber dafür reicht eine Namenskonvention. Hat mich jemals der Compiler darauf hingewiesen, dass ich versuche, eine Konstante zu ändern? Nicht, dass ich mich erinnern könnte.

Buchtipp “Clean Code”

Das Buch “Clean Code” von Robert Martin stand schon eine Weile in meinem Bücherregal. Ich habe es solange aufgeschobene, weil ich für mich wenig Neues erwartete. Jetzt bin ich dann endlich dazu gekommen, das Buch zu lesen. Ich hatte vor, es zu überfliegen, weil der Inhalt für mich mit 10 Jahren agiler Programmiererfahrung nicht wirklich neu sein kann.

Wirklich neu war der Inhalt auch nicht, aber aus dem Überfliegen ist auch nichts geworden. Zum einen ist das Buch so kurzweilig geschrieben, dass das Lesen Spaß macht. Zum anderen waren doch einige Abschnitte drin, die mich überrascht und zum Nachdenken angeregt haben.

Die grundsätzliche Argumentation des Buches ist, dass man sich auch um die Kleinigkeiten kümmern muss. Das ist erstmal konträr zu dem, was ich im Studium gelernt habe. Dort war eine Hauptmotivation für Module, dass man in denen das Chaos einsperren kann. Demnach müsste man die Makrostruktur sauber halten und muss sich um die Interna der Module nicht so sehr kümmern. Klang logisch. Aber sowas habe ich in 18 jahren kommerzieller Softwareentwicklung nicht erlebt. Entweder war das System auf jeder Ebene gut strukturiert oder auf jeder Ebene vergurkt. Ich denke, das hängt mit der Einstellung der Entwickler zusammen. Entweder sie interessieren sich für Qualität. Dann tun sie das auf jeder Ebene. Oder sie interessieren sich nicht für Qualität. Dann kümmern sie sich auch nicht um eine vernünftige Makro-Struktur. Robert Martin hat also Recht: Wir müssen uns um sauberen Code auch auf Mikro-Ebene kümmern.

Nur ein Beispiel für die Überraschungen, die das Buch für mich bereit hielt Robert Martin vertritt die Ansicht, dass eine Methode mit einem Parameter schon komplex ist und wenn möglich vermieden werden sollte. Mit 2 oder 3 Parametern wird es demnach noch viel schlimmer. Zuerst habe ich gedacht “naja…”. Aber seine Argumente sind gut und er hat Recht. Viele Parameter sind in sich komplex und deuten häufig darauf hin, dass wir zusätzliche Klassen benötigen oder Methoden in andere Klassen verschoben werden sollten.

Fazit: Aus meiner Sicht ist “Clean Code” ein Must-Have für jeden professionellen Softwareentwickler – egal ob agil oder nicht. Auch alte Hasen werden Nutzen daraus ziehen können.

Festpreise, Aufwandsprojekte und dann?

Vor kurzem habe ich hier zu Festpreisen und Aufwandsprojekten geschrieben. Und ich hatte versprochen noch etwas mehr dazu zu schreiben.
Das große Problem an beiden Vertragsformen ist ihre Kostenorientierung. Die Kosten stehen im Vordergrund und damit gehen auch immer alle Diskussionen in Richtung Kostenreduktion.
Ich möchte keine Kostenstelle sein! Ich will Geschäftswert schaffen.
Wie wäre es also zur Abwechslung mal mit wertorientierten Vertragsformen? Warum lassen wir uns als Softwareentwickler nicht prozentual an den Werten beteiligen, die unsere Software für den Auftraggeber schafft?
Dann haben Auftragnehmer und Auftraggeber dasselbe Ziel. Und wenn der Auftragnehmer durch Scrum ganz furchtbar produktiv wird, profitiert er auch davon.
Neu ist die Idee übrigens nicht. Kent Beck hat schon in der zweiten Auflage des XP-Buchs “Pay per Use” gefordert; ein mögliches Vertragsmodell, aber nicht das einzige.

Code Kata Bunkai: Prime Factors

Bernd Schiffer has published a screencast of the Prime Factors Code Kata that we prepared.
When a programmer new to TDD watches such a code kata he has the same problem that an unexperiences karate student has when he watches a karate kata. He can see what’s happening but he has no idea why.
In karate there is a second kata flavour: Bunkai:

Bunkai literally meaning “analysis” or “disassembly”, is a term used in Japanese martial arts referring to the application of fighting techniques extracted from the moves of a “form” (kata) (see Wikipedia).

When watching a kata bunkai it becomes pretty obvious why the moves of the kata are done.
The same should be possible with code katas. Therefore we tried to transfer the bunkai concept to code katas. For now that simply means that the non obvious parts of the code kata are explained. I published the result for the prime factors code kata on YouTube.

I have to confess that I simply cut Bernds video. I think the real code kata bunkai should include the explanation in the kata – like it is in karate. We will work on that.

Festpreise und schneller durch Scrum

Boris Gloger hat zwei Blogeinträge zu Festpreisen und Scrum geschrieben (hier und da) und dabei interessante Thesen vertreten. Die Abrechnung
nach Time&Material könne problematisch sein, wenn man nach Scrum arbeitet. Sein Argument ist, dass der Anbieter dann einfach Tagessätze abrechnet und keine große Motivation hat, effektiver zu arbeiten. Aber genau dafür sei Scrum da: effektiver Arbeiten. Ich finde das Argument soweit nachvollziehbar.

Eine Alternative dazu könne ein Festpreis sein – das vertritt auch Jeff Sutherland mit seinem “Money for Nothing, Change for Free”. Wer Scrum richtig macht, sei deutlich effizienter als ein klassischer Anbieter und könne daher mit Festpreisen sehr hohe Margen erreichen. Auch das finde ich erstmal nachvollziehbar.

Aber:

Wir haben uns vor ein paar Jahren um ein Multi-Millionen-Euro-Projekt beworben. Nach einigen Auswahlrunden waren noch wir übrig und ein anderer Anbieter. Der andere Anbieter geht klassisch vor und ist viel größer als wir. Wir haben die Entwicklung zu einem Bruchteil des Preises angeboten, die der andere Anbieter angeboten hat. Ich glaube, unsere Aufwandsschätzung hätte gepasst. Wir wären also tatsächlich deutlich effektiver gewesen als der Anbieter. Scrum sei Dank.

Und jetzt passierte etwas sehr Merkwürdiges. Der Auftraggeber meldete sich bei uns und meinte, unser Angebot sei zu billig und damit
unglaubwürdig. Uns wurde empfohlen, Aufwände für Projektleitung, Testen, Dokumentation etc. extra auszuweisen und damit den Aufwand in “glaubwürdige” Regionen zu bringen. Also haben wir das gemacht. Letztlich waren wir damit immer noch erkennbar günstiger als der andere Anbieter, aber nicht mehr so dramatisch. Und wir haben unsere Margen erhöht.

Damit war der Auftraggeber zufrieden und hat sich für den anderen Anbieter entschieden. Die Argumentation des Vorstandes ging dann wahrscheinlich so: “OK, A ist etwas günstiger, aber B ist größer. Da sind wir auf der sicheren Seite. Also nehmen wir die Mehrkosten in Kauf.”

Dass wir soviel effektiver waren als die Konkurrenz hat uns also gar nichts genützt.

Ich glaube, es gibt jenseits von Time&Material und Festpreis andere Vertragsmodelle, die besser zu Scrum passen (und natürlich kann man prinzipiell Time&Material und Festpreise mit Scrum machen). Ich werde dazu später noch etwas schreiben.

Scrum bei Startups

In meinen Scrum-Kursen begegne ich immer häufiger Leuten, die direkt oder indirekt davon betroffen sind, dass Venture-Capital-Geber (VCs) wünschen, dass IT-Startups Scrum einsetzen. Bei einigen Geldgebern gibt es wohl gar keine Kohle mehr für IT-Startups, wenn sie nicht Scrum machen.

Das ist auf jeden Fall ein starkes Signal. Der Job der VCs besteht darin, die erfolgversprechenden Startups von denen zu unterscheiden, die keine Chance auf Erfolg haben. Und wenn die VCs jetzt immer stärker in Richtung Scrum drängen, dann bedeutet das wohl, dass sie Scrum als Erfolgsfaktor für Startups ausgemacht haben.

Das bedeutet natürlich noch lange nicht, dass die VCs wirklich verstanden haben, was Scrum ist. Aber das spielt in ihrer Position auch höchstens eine untergeordnete Rolle. Oder doch? Brauchen wir “Scrum für VCs”-Kurse?

Ob es viel bringt, die Startups zu Scrum zu zwingen kann man natürlich in Frage stellen. Wenn die Startups das nicht von sich aus wollen, werden sie Scrum wahrscheinlich auch nicht richtig hinkriegen. Sie werden Scrum bei Bedarf mit mehr oder weniger großem schauspielerischem Talent aufführen: Scrum-Schauspieler. Aber dadurch erreichen sie die erhofften Effekte nicht.

Es gibt allerdings auch Startups, die Scrum bisher einfach nicht oder nicht richtig kennen. Und da kann ein Schubs in Richtung Scrum durchaus hilfreich sein.

Buch: x-teams

Ich habe gerade das Buch “x-teams” von Deborah Ancona und Henrik Bresman gelesen.

Es geht im Buch um eine besondere Art von Teams, die sogenannten x-teams, die besonders gut in hochkomplexen Umgebungen funktionieren:

  1. x-teams sind innovativ.
  2. x-teams haben in ihrem Lebenszyklus unterschiedliche Schwerpunktsetzungen: Explore, Exploit, Export. Zunächst wird das Umfeld exploriert, um die Situation zu verstehen. Anschließend wird eine Idee oder ein Produkt ausgearbeitet und umgesetzt. Und zuletzt werden die Ergebnisse in den Markt und das eigene Unternehmen exportiert.
  3. x-teams beschäftigen sich nicht primär mit sich selbst, sondern managen stets auch die Beziehungen zu ihrem Umfeld, den Stakeholdern etc.
  4. x-teams haben wechselnde Mitglieder, abhängig von den Lebenszyklus-Phasen.

Diese Eigenschaften basieren auf Untersuchungen erfolgreicher Teams bei Microsoft, BP, P&G, etc. Bei diesen Teams handelte es sich nicht nur um IT-Teams.

Es gibt hier offensichtliche Parallelen zu Scrum oder anderen agilen Ansätzen:

  1. Scrum dient der Entwicklung innovativer Produkte.
  2. Meistens werden bei agilen Ansätzen zwei “Phasen” unterschieden: Envisioning (=Explore) und Entwicklung (=Exploit). Der Export-Teil fehlt hingegen als explizites Element. Ich habe nur sehr fragmentarisches Wissen über die Ursachen, warum eXtreme Programming bei Crysler letztlich beendet wurde. Möglicherweise hat der Export gefehlt?
  3. Scrum sieht den Product Owner als primäre Schnittstelle zur Außenwelt vor, in XP war es der On-Site-Customer. x-teams deuten darauf hin, dass wir diese Schnittstelle nicht zu strikt begreifen sollten. Alle Teammitglieder sollen und dürfen Kontakt zu Anwendern und anderen Stakeholdern haben. Es muss halt nur klar sein, wer letztlich den Geschäftswert einschätzt und die Priorisierung vornimmt.
  4. Wir weisen immer gerne darauf hin, dass Teambildung erhebliche Kosten verursachen kann und man daher nicht jeden Sprint das halbe Team austauschen sollte. Wir sollten es damit aber auch nicht übertreiben und gar keinen personellen Wechsel mehr erlauben.

Aus meiner Sicht liefert das Buch ein paar neue Erkenntnisse und Denkmodelle, aber nichts gravierend Neues. Dadurch hat es sich für mich dann auch nicht so interessant gelesen.