Open Forum 2011 - ready, set, change!

Im Open Change-Forum findet sich eine erste Zusammenfassung von Eindrücken und Gedanken zur diesjährigen Konferenz in Stuttgart:
http://openchange.wordpress.com/2011/07/13/ready-set-change/

Sichere Innovation, innovativ sicher?

Innovation bedeutet, dass Innovatoren ständig neue Dinge vorantreiben und dabei sogar vielleicht eigene vorher eingeführte Ideen bekämpfen müssen. Geht dadurch Sicherheit verloren? In gewisser Weise ja, denn es gibt keinen ständig gleichen Zustand mehr. Aber Sicherheit kann sich auf viel mehr beziehen: Funktionen von Geräten, Schutz vor Gefahren, das Funktionieren von Organisationen und es braucht auch ein gewisses Maß an Selbst-Sicherheit um Innovationen anzugehen.

Vor diesem Hintergrund diskutierten Harald Heinecke (BMW Car IT) „Kontinuierliche Innovation“ und Dr. Klaus-Rüdiger Hase (Deutsche Bahn, Systemverbund Bahn - Beschaffung) „openETCS – An ‚open proofs‘ approach for the European Train Control System“. Bei letzterem Vortrag ging es dabei um die Einführung des European Train Control System (ETCS) – einem sicherheitskritischen System:

• Typische Qualität von Software 1-12 Bugs pro 1000 Lines of Code
• Höchste Softwarequalität bisher 1 Bug pro 10.000 Lines of Code – US Space Shuttle, 3 Millionen Zeilen für 3 Millarden
• Typische ETCS-Software-Komponenten haben 100 bis 500.000 Lines of Codes
• Daumenregel bei der Entwicklung von Software 10% mehr Funktionen 100% mehr Fehler
• „Open proof“ = Quellcode, Beweise und Werkzeuge (Open-Source)
• Umstellung von Closed Source nach Open Source: Wechsel der Lizenz und Veröffentlichung einer offenen API, schließlich Schaffung einer unabhängigen Organisation.

Den Hintergrund hierfür bildete der erste Vortrag:

• Führungskräfte sind Teil des Systems, das sie selbst gestalten.
• Dynaxity aus Dynamik und Komplexität (Heijo Rieckmann)
• Veränderung berührt Werte und Normen, Fähigkeiten, Management Systeme und physikalische Systeme in einem Aufgabenkreis Experimentieren, Idee/Import von Wissen, Problemlösung, Implementierung
• Das Wort „Aber“ ist der Innovationskiller Nummer 1.
• Es gibt keine Innovation die nicht durch Software implementiert werden kann.
• Ständiges Monitoring ermöglicht das Erkennen von Erfolgsfaktorenveränderung.
• Kontinuierliche Innovation braucht man eine ständige Weiterentwicklung und Monitoring.

Sicher war am Ende des Session: Alle Teilnehmerinnen und Teilnehmer haben etwas gelernt und intensiv diskutiert, wie man Innovation proaktiv angehen und steuern kann. Klar wurde auch: Am Ende zählt der Mensch.

Testing the Tester

"Coder wollen coden bis zum Schluss, aber niemand will debuggen&testen." - so hat einer der Referenten am Vormittag den Nagel auf den Kopf getroffen.
In diesem Licht erschien der Nachmittagstrack gewissermaßen als "deus ex machina" - was ihm aber keinesfalls zum Nachteil gereichte, sondern vielmehr für anregende Diskussionen sorgte.

Zum Abschluss der Konferenz haben die Vortragenden über das Wechselspiel zwischen Testen und Innovation in ihrer Organisation berichtet und gezeigt, wie fruchtbar es sein kann, den ganzen Entwicklungszyklus als Inspirationsquelle zu nutzen - einerseits um das Testen selbst angenehmer und effektiver zu gestalten, andererseits um Weiterentwicklungen in anderen Bereichen anzustossen.

Den Auftakt machte Stefan Schmierer von BMW und schilderte wie die von ihnen entwickelte ARUnit es ermöglicht, in C implementierte AUTOSAR (AUTomotive Open System ARchitecture) mithilfe von Java-basierten Frameworks zu testen.

Danach zeigte uns Predrag Skokovic (Execom d.o.o.) ein ad hoc entwickeltes Open-Source Plug-In mit dem sich das Testen in Eclipse integrieren lässt. Einmal wieder zeigt sich bei diesem Projekt der Vorzug offenen Quellcodes - so kann man beispielweise je nach zu testender Applikation sich mit dem Auftraggeber austauschen und das Tool zusammen passgenau fine-tunen.

Das Finale bildete der Vortrag von Christine Mitterbauer von MicroDoc. An einem Fallbeispiel aus ihrer Firma zeigte sie, wie Test Driven Development genutzt werden kann, um positive Externalitäten zu erzeugen. Sauber programmierte virtuelle Prototypen können nämlich vielfältig eingesetzt werden, um die Effektivität ganz verschidener Bereiche zu erhöhen. Man kann mit solchen Prototypen vorab schon die Enduser schulen, man kann die Prototypen als Marketing-Tool verwenden, man kann Simulationen für die Supportabteilung durchführen...es ist ein weites Feld und man wird in Zukunft sicherlich noch mehr zu dem Thema hören.

Beschleunigen und Bremsen rund ums Auto

Die Nachmittagssession am Mittwochnachmittag stand unter der Überschrift Nicht-Technische Bremsen und Beschleuniger. Konkret vorstellbar sicherlich am Automobil, welches auch bei Simon Schmitz (tarent AG) und seinem Thema „Identität Auto – wie Software die Autoindustrie verändert“ im Mittelpunkt stand. Obwohl nicht wirklich das Auto als Ganzes sondern die Software darin. Diese eingebetteten Systeme waren auch der Gegenstand des Vortrags „Praktische Maßnahmen bei möglichem Eingriff in Patente/Urheberrechte durch Embeded Software“ von Alexander Bach (Patent- und Rechtsanwalt, Diplom-Informatiker). Der Jurist arbeitete den Unterschied zwischen Unterschied zwischen Patent- und Urheberrecht heraus: Software wird durch Urheberrecht erfasst. Im deutschen Patentrecht ist Software als solche nicht patentierbar, aber Embedded Software ist nicht gewöhnlich. Urheberrecht für die Gestalt, nicht die Idee und Grundsätze. Patentrecht schützt die Idee. Dieses im Hinterkopf wurde es spannend zu sehen, dass die eingebetteten Softwaresysteme in der Automobilbranche noch stärker durch die Kunden und ihre Ablehnung gebremst werden als durch Technik und Recht. Dennoch bleiben rechtliche (Urheber-, Patent-, Zuwanderungsrecht) und politische (Förderung des Interesses von Jugendlichen an Technik) Rahmenbedingungen der entscheidende Faktor für die Zukunft der deutschen und europäischen Automobilbranche.

(Der dritte Vortrag in der Session zum Flow State ist hier.)

Der Flow State

Roland Lehle spricht zum Flow State - als Paradigma, als Lebensgefühl. Mit einer ungewöhnlichen Präsentation.

Flow state and KANBAN on Prezi

Selbstorganisation kommt von selbst organisieren

Der Mittwochvormittag stand ganz im Zeichen des Stichworts Selbstorganisation. Vier intensive Referate versuchten sich dem Thema aus unterschiedlichen Blickwinkeln zu nähern.

Den Aufschlag übernahm Dr. Andreas Winklhofer (Mai Consulting) mit „IT Changes: Wie man Veränderungen durch und in der IT gestalten kann“. Dann übernahmen Lilian Matischok (cross  ing) und  Michael Thiel (cinco.systems) mit ihrem Vortrag “Steuern Sie schon oder rudern Sie nur? Wie selbstbestimmte Teams zu fremden Küsten vordringen“. Hiernach sprach Elke Koll über „Selbstbestimmte Teams und IT – Effizienz durch Diversity Management?!“, bevor Tim Weilkiens (oose) mit „Agilität im starren Umfeld – hart aber agil“ den Abschluss übernahm.

Was waren die Lessons learned aus dieser Session?

Einerseits steigen Komplexität und Dynamik in der Wirtschaft immer weiter an, so dass Selbstorganisation, cross-funktionale Teams und Netzwerke immer wichtiger werden. Diese erfordern neue Formen der Organisation, des Management sowie Werte und Prinzipien. Werte und Prinzipien bilden dabei die Grundlage für das entsprechende Vorgehen(smodell), welches sich in Praktiken manifestiert. Gleichzeitig werden durch Globalisierung, Migration, Gesetze und die neuen (agilen) Führungs- und Teammodelle auch das Anerkennen von Vielfalt, Unterschiedlichkeit und Andres sein des Einzelnen immer entscheidender. Trotz der zunehmenden Eigenverantwortung von Teams für Kosten, Budgets und Aufgabenverteilung wird aber die Führungskraft nicht verschwinden, sondern sich zunehmend als Coach für das Team wiederfinden.

Entscheidend ein Satz für alle in Beratung und Begleitung von Veränderungsprozessen tätigen: „Methoden / Tools sind einfach, wesentlich ist die Beraterhaltung“ (Vortrag Dr. Winklhofer). Dieser Satz lässt sich auch verallgemeinern auf Führung insgesamt, denn die Haltung gegenüber den Menschen und dem Neuen macht’s.

Dem Cargo-Kult vorbeugen

Als die amerikanischen Soldaten ihre Stützpunkte auf den polynesischen Inseln verließen, fielen plötzlich keine Versorgungsfallschrime vom Himmel. Also beschlosssen die Ureinwohner die Amerikaner zu emulieren, in der Hoffnung, dass dadurch die begehrten Flugkörper zurückkommen. Sie schnitzen sich Funkgeräte und Kopfhörer, spielten Flugplatzbesatzungen nach und versuchten, sich wie Soldaten zu kleiden. Gebracht hat es nichts.
Genausowenig bringt es, Gerede um "Agile" zu erzeugen, ohne es eigentlich zu leben. George Mesesan - Evangelist von "Agile" bei MicroDoc - hat einen Querschnitt durch die Idee, die Wertesysteme und Kultur von Agile gegeben. Dreh- und Angelpunkt ist und bleibt der Code. Falls nicht von Anfang an sauber und strukturiert gecodet wird, tritt zwangsläufig der "Broken Window"-Effekt ein: fängt man erstmal an, schlampig zu programmieren, beginnen die Nachlässigkeiten, sich durch den gesamten Quellcode zu schlängeln.
Daher muss die Devise stets heissen: Lesbarer Code, konsequentes Debuggen (auch wenn, bzw. gerade weil es eine unbeliebte Tätigkeit ist) und Übernahme von "ownership". Nur so kann man "Agile" nicht nur predigen, sondern auch tatsächlich leben.