Neue XING-Gruppe zu Lean Software Development

Gemeinsam mit Traian Kaiser, Ralf Wirdemann und Stefan Roock habe wir auf XING ein neues Forum zum Thema „Lean Software Management“ gestartet. Lesen ist frei, wer mitdiskutieren möchte, muss sich bei XING und in der Gruppe anmelden.

Zur Erinngerung: Lean Software Development ist eine „Unterdisziplin“ der agilen Verfahren, die versucht, die Lehren und Erkenntnisse aus Lean Management und Lean Development von der Autoindustrie – und da vor allem von Toyota – auf die Entwicklung von Software zu übertragen. Basis sind vor allem die Arbeiten von Mary und Tom Poppendieck und ihre Bücher Lean Development Software: An Agile Toolkit for Software Development Managers und Implementing Lean Software Development: From Concept to Cash. Das Ergebnis ist erstaunlich ähnlich zu anderen agilen Verfahren wie Scrum etc., konzentriert sich aber deutlich mehr auf Zusammenhänge und weniger auf die genaue Einhaltung von Praktiken.

Eine Kurzfassung findet man in einem zweiteiligen Artikel von Mary Poppendieck und mir:

CSM+Crystal Kurse mit Alistair Cockburn

Wie ich bereits vor vier Wochen angekündigt hatte, biete ich gemeinsam mit dem Scrum-Center und andrena objects zwei dreitägige CSM-Kurse inklusive Einführung in Crystal mit Alistair Cockburn an. Die Kurse finden statt am:

Die Kursgebühr beträgt € 1800,00 zzgl. MWSt. Wer jemals einen Workshop mit Alistair erlebt hat, weiß dass sich die Investition lohnt.

Die Kurse finden in Englisch statt, Rückfragen können aber auch auf Deutsch gestellt werden.

Darüber hinaus gibt es auch noch die Möglichkeit von Inhouse-Workshops mit Alistair Cockburn und mir oder Alistair Cockburn alleine. Anfragen können Sie per E-Mail an mich senden.


Kursbeschreibung von Alistair

Alistair Cockburn
Certified Scrum Master and Introduction into the Crystal method family

This workshop is based on the award-winning book Agile Software Development: The Cooperative Game, on Crystal Clear: A Human-Powered Methodology for Small Teams, and on Agile Project Management with Scrum. The first part of the course gives the attendee a gut feeling for the is and isn’t of agile development; the second sets out Scrum and the role of the ScrumMaster; the third introduces Crystal with it’s 7 Properties of Highly Successful Projects.

Each part introduces its concepts with small lecture, followed by team activities to anchor them. The activities are constructed to give attendees a sense for how it feels to be doing some of the key practices as well as what how it feels not to do them. The techniques reviewed are valuable in carrying out any kind of project, not only agile ones.

  • Basic Agile
    • How to understand agile development in the larger context of real-world software development.
    • Cooperation, communication, incremental development and reflection as critical factors in project success.
  • Scrum
    • The heart of Scrum: collaborate & deliver; inspect & adapt.
    • The ScrumMaster role (including becoming a Certified ScrumMaster)
  • Crystal
    • How Crystal’s reflection adds to generic agile and generic Scrum.
    • Applying the 7 properties of highly successful projects

Course Goal for Attendees

  • Understand what is agile and what isn’t agile development
  • Have a gut feeling for teamwork, communication, frequent customer interaction and frequent delivery
  • Understand Scrum, the role of the ScrumMaster, and the Crystal methodology family as techniques in setting up and running projects
  • Have a few techniques to take home and use immediately
  • Walk away with a „Certified ScrumMaster“ certificate

Instructor

Dr. Alistair Cockburn, author of the Jolt-award winning books, Agile Software Development: The Cooperative Game and Writing Effective Use Cases , coauthor of the Agile Manifesto and Project Management Declaration of Interdependence, and Certified Scrum Trainer.

Level: Beginner and Intermediate

Who Should Attend: Participants keep saying, „I wish my boss had come to this!“, so it is a good idea if people from every level and role attend.

Alistair Cockburn gibt CSM-Kurs in Deutschland im November

In Zusammenarbeit mit dem Scrum-Center und andrena objects ist es uns möglich, voraussichtlich zwei dreitägige CSM-Kurse mit Alistair Cockburn in der zweiten Hälfte November anbieten zu können. In Planung ist derzeit ein Kurs in München und einer in Frankfurt. Bei mindestens einem davon werde ich assistieren.

Zudem gibt es ein kleines Zeitkontingent für Inhouse-Workshops entweder mit Alistair alleine oder Alistair und mir gemeinsam.

Alistair ist der Schöpfer der Crystal Methodenfamilie und einer der Autoren des agilen Manifests. Ich persönlich habe nicht nur einen großen Teil meines eigenen agilen Handwerks von ihm gelernt, sondern auch seinen interaktiven Stil in Workshops und Schulungen immer sehr genossen. Dies ist eine seltene Gelegenheit für alle, die Agilität von einem ihrer Schöpfer kennen lernen wollen und dabei auch noch ein Zertifikat als „Certified Scrum Master“ erhalten wollen. Die Kurse werden in Englisch stattfinden, Alistair spricht aber gut genug Deutsch, um auch auf deutsch gestellte Fragen beantworten zu können.

Nähere Informationen zu den Schulungen werden wir im Laufe der nächsten Wochen veröffentlichen. Bei Interesse an Inhouse-Workshops wenden Sie sich bitte an mich.

Folien der Karlsruher Entwicklertage online

Zu meinen Vorträge auf den Karlsruher Entwicklertagen stehen nun auch die Folien online zur Verfügung:

Danke an die andrena objects ag für das Bereitstellen der Unterlagen

Der SPIEGEL zum Erfolg von Extreme Programming bei Microsoft

Allen, die agile Entwicklung noch immer für eine Absurdität unprofessioneller Hobbyentwickler und Hippies halten, sei der Artikel „Windows aus der Asche“ aus dem aktuellen SPIEGEL empfohlen, der auch auf SPIEGEL-Online verfügbar ist. Der Beitrag berichtet, wie Microsoft für die Entwicklung von Windows 7 konsequent auf Extreme Programming gesetzt hat („Von nun an, so viel stand fest, sollte der Kunde treiben“ und „in ganzen Abteilungen sitzen die teuren Programmierer nicht mehr allein, sondern paarweise vor den Monitoren“; „Beginne mit dem Machbaren, dann füge Stück für Stück hinzu. Und immer gleich gründlich testen!“) und welche Auswirkungen das hatte: „Plötzlich kommen der Reihe nach Produkte heraus, die den fast ungeteilten Beifall der Fachwelt finden“, und Brad Silverberg, Entwicklungsleiter von Windows 95, stellt fest: „Zum ersten Mal seit langer Zeit sind die Leute wirklich entzückt von neuen Microsoft-Produkten.“ Auch Qualität und Terminplanung wurden beeinflusst: „Windows 7 […] ist nun nach kaum zwei Jahren fast fertig. Und der Start wurde schon zweimal vorverlegt, zuletzt auf den 22. Oktober.“

Ich denke, damit dürfte die Brauchbarkeit agiler Verfahren auch für große und schwierige Projekte endgültig empirisch gezeigt sein. Anders formuliert, agile Entwicklung ist jetzt nicht mehr nur Sache der Pioniere, sondern wird nach und nach zum entscheidenden Wettbewerbsvorteil — ein Vorteil, den vor Microsoft auch schon Google, Amazon und ebay genutzt haben.

Ich hoffe nur, dass die deutsche IT-Industrie hier nicht wieder durch „aktives Zuwarten“ den Zug verpasst und weitere Arbeitsplätze gefährdet, sondern erkennt, dass es höchste Zeit wird, sich umfangreiches Know-How und Praxis angzueignen. Es ist schließlich wesentlich einfacher, die Organisation noch umzustellen, solange man das nach eigenem Zeitplan machen kann, als wenn man von der Konkurrenz vor sich her getrieben wird.

Kundennutzen in Agilen Projekten

Felix Rüssel hat vor einiger Zeit in seinem — übrigens insgesamt sehr lesenswerten — Blog einen älteren Beitrag von mir zum Kundennutzen unter dem Titel „Kundenzufriedenheit vs Kosten“ in die Kritik genommen. Einer von Felix‘ Kernsätze war: „Die agile Sichtweise schlägt […] stark vereinfacht vor, Kundennutzen grundsätzlich zu maximieren. Dies darf jedoch nicht zu Lasten des Gesamtbudgets des Projektes gehen! Dieser Konflikt muss durch den ProductOwner bzw. den Projektleiter erkannt und zusammen mit dem Kunden gelöst werden“, und er beklagt sich: „Die Kundenzufriedenheit spielt […] unbestritten eine zentrale Rolle, wird jedoch gerade in der agilen Welt zu oft als alleiniges Heilmittel angesehen. Es wird oft aus der Sicht des Ingenieurs argumentiert, der Prozesse und Arbeitsergebnisse optimieren möchte.“

Ich teile Felix‘ Auffassung nicht, dass die alleinige Fokussierung auf die Kundenzufriedenheit nur aus einer technokratischen Sicht kommt. Ich denke, sie hat auch handfeste betriebswirtschaftliche Gründe, zumindest wenn der Kontext stimmt. Felix argumentiert in seinem Beitrag aus der Sicht eines Softwarehauses: „In den meisten Fällen arbeiten heute Teams in der Projektentwicklung weiterhin mit Werkverträgen, d.h. es wird ein definiertes Ergebnis zu einem bestimmten Termin geschuldet.“ Das bedeutet aber eben nicht nur ein Werkvertrag, sondern auch eine neue, künstlich eingezogene betriebswirtschaftliche Ebene: Für den Auftragnehmer ist in dieser Situation nicht mehr der betriebswirtschaftliche Erfolg der Software relevant, sondern einzig der Erfolg des Projekts ihrer Erstellung, gemessen an Einhaltung von Umfang und Termin möglichst unterhalb des Budgets und zu einer Qualität, die mir nicht gerichtsfest um die Ohren geschlagen werden kann.

Je weiter ich als Projektleiter also kurzfristige Kosten und damit Qualität nach unten drücken kann, um so erfolgreicher bin ich betriebswirtschaftlich als Projekthaus. Allerdings werden dabei die Kosten nicht wirklich reduziert, sondern nur vom Auftragnehmer zum Auftraggeber verlagert: Der Auftragnehmer spart vor der Produktionssetzung Kosten ein, indem er weniger in Qualität investiert, der Auftraggeber muss ein Mehrfaches dieser Kosten hinterher aufbringen, um die Fehler zu beheben, mit den Fehlerfolgen umzugehen und das verkorkste Design weiter zu entwickeln. In der Rechtstheorie könnte er dafür zwar den Auftragnehmer in Mängelhaftung nehmen, in der Praxis ist das jedoch nicht nachzuweisen.

Rob Austin bezeichnet diese Konstellation in einem meiner Lieblingsbücher „Measuring and Managing Performance in Organizations“ als „Measurement Distortion“: Wenn ein System (oder Vertrag) von vier Parametern bestimmt wird (Termin, Umfang, Kosten und Qualität) und ich kann nur drei von ihnen einigermaßen messen (Termin, Umfang und Kosten), so werden diese auf Kosten des schlecht messbaren vierten Parameters (Qualität) optimiert. Wie das im Projektalltag dann aussieht, beschreibt Felix sehr richtig und treffend.

Die Schlussfolgerung ist aber nicht, dass Agilisten „das Thema ‚Kosten‘ gerne verdrängen“ würden, sondern dass Werkverträge nicht geeignet sind, betriebswirtschaftlich sinnvoll ein Softwaresystem zu erstellen: Hier geht es ja nicht nur um Entwicklungskosten (die der Auftragnehmer eines Werkvertrages optimiert), sondern um die Gesamtkosten („Total Cost of Ownership“) des Systems, zu denen unter anderem auch Betriebs-, Wartungs-, Weiterentwicklungs- und Stilllegungskosten gehören. Die Rechnung wird also am Ende der Lebenszeit der Software aufgemacht, nicht zu Produktionsstart. Um die Tatsache abzubilden, dass bei den Kosten auch der Zeitfaktor mitspielt, arbeiten Betriebswirtschaftler mit Abzinsungsmodellen, die ein guter Product Owner meines Erachtens kennen und soweit sinnvoll berücksichtigen sollte. Mike Cohn beschreibt solche Modelle sehr gut in seinem Buch „Agile Estimating and Planning„, Kapitel 10.

Die agile Sicht stellt also dem traditionellen Projekt „Software bis zur Produktionsreife entwickeln“ eine Produktsicht gegenüber: Der Return-on-Investment über den gesamten Lebenszyklus muss optimiert werden. Ich habe diesen Gedanken 2005 einmal in dem Artikel „Projektdämmerung“ weiter ausgeführt. Es geht also um eine globale Optimierung statt einer lokalen, bzw. um eine ganzheitlichere Sicht auch in der betriebswirtschaftlichen Steuerung. In Scrum ist genau das die Aufgabe des Product Owners.

Mit anderen Worten: Die Abkehr vom Werkvertrag ist für den Auftraggeber wichtig und sinnvoll. Die Auftragnehmer haben sich mit Werkverträgen arrangiert, vom meist agilen, kundenorientierten Softwarehaus, das sich bemüht, das Spannungsfeld für alle Seiten einigermäßen erträglich auszubalanzieren bis zum eiskalten Homo Ökonomicus im Großkonzern, für den nur noch Termine und Kostenminimierung zählen und die nicht vertraglich fixierten Interessen des Kunden keine Rolle mehr spielen. Der Auftraggeber liefert sich in beiden Fällen ohne Not dem Auftragnehmer aus, seine Interessen kommen dabei in der Regel unter die Räder.

Aufruf zu Einreichungen für die XPDays 2009

Auch heuer findet die (meines Wissens) größte deutschsprachige methodenübergreifende Konferenz zu agiler Entwicklung, die XPDays 2009, wieder Ende November statt, turnusmäßig im schönen Karlsruhe. Wer etwas beitragen möchte, findet den offiziellen Aufruf zu Einreichungen unter http://xpdays.de/2009/callforsessions.html, spätester Termin ist der 31.7.09; wer früher einreicht, bekommt besseres und mehr Feedback und noch eine Chance, die Einreichung zu verbessern. Es gibt nämlich einen offenen Reviewprozess, an dem jeder teilnehmen kann, der sich dazu berufen fühlt.

Certified Scrum Developer und implizites Wissen

Die Scrum Alliance arbeitet derzeit an einem „Certified Scrum Developer“. Nun gut, das bisherige Zertifizierungsprogramm aus Scrum Master, Product Owner, Practitioner, Coach und Trainer hat nicht unwesentlich zum Markterfolg von Scrum und Agilität beigetragen; und welche Folgen es für den Ruf von Scrum und agilen Verfahren hat, wenn 50.000 Scrum „Master“ mit einer jeweils zweitägigen Schulung unterschiedlicher Qualität die Industrie stürmen, um es jetzt „richtig“ zu machen, wird die Zukunft zeigen. Warum also das Erfolgsrezept nicht auch auf Entwickler ausdehnen?

Die Antwort ist einfach: Den Schaden, den ein schlechter Entwickler anrichten kann, ist für das Projekt noch bei weitem höher, als den, den ein schlechter Scrum Master anrichten kann: Den Scrum Master tauscht man zur Not aus und muss dann das Team wieder neu aufbauen und motivieren. Das kostet Geld, Zeit und Nerven, ist aber machbar. Schlechte Entwickler aber hinterlassen ihre Hypotheken im Code, die neue Hypotheken nach sich ziehen, ähnlich wie die Verpflichtungen der HRE.

Software Entwicklung ist in hohem Maße erfahrungs-getrieben. Dies gilt insbesondere für testgetriebene Entwicklung und emergente Architekturen, wie sie im Extreme Programming eingeführt und mittlerweile von allen agilen Verfahren inklusive Scrum übernommen wurden (leider nicht immer mit den gebotenen Referenzen). Erfahrungsgetrieben bedeutet aber, dass viel erfahrungsgebundenes implizites Wissen notwendig ist. Wikipedia beschreibt dieses Wissen folgendermaßen:

„Damit ist ein Wissen gemeint, das sprachlich nicht oder kaum weitergegeben werden kann. In solchen Fällen muss der Betreffende durch eigene Erfahrung oder am Modell lernen, das ihm vorzeigt, was nicht vorgesagt werden kann. Beispiel: Wer guten Nudelteig machen möchte, kann Rezeptbücher lesen. Aber in diesen Büchern steht offenbar nicht alles, was gute Teigköche wissen, weil dies nicht vollständig verbalisierbar ist. Das Gefühl für die richtige „Nässe“ des Teigs beispielsweise erwirbt man nur durch Erfahrung.“

Sicher, gerade die Patternbewegung hat sich erhebliche Verdienste erworben, Teile dieses impliziten Wissens zu heben und explizit zu machen, aber eben nur Teile. Die Eleganz eines Designs, die Strategie eines Umbaus lässt sich ebenso wenig explizieren, wie die Struktur eines Teiges. Hier hilft nur: Üben, üben, üben, viele Erfahrungen machen. Aber auch aus den Erfahrungen anderer lernen, fremden Code ansehen, fremde Architekturen — und zwar nicht nur den Beispielcode des MSDN.

Mir ist unbegreiflich, wie sich Informatik-Professoren damit schmücken können, in ihrem Leben keine 1000 Zeilen Code geschrieben zu haben, wie Architekten stolz darauf sein können „nicht mehr zu programmieren“ (man vergebe mir, dass ich hier keine Namen nenne). Kennen Sie einen Chirurgen, der sich damit brüstet, in seinem Leben kaum mehr operiert zu haben, als drei Platzwunden zu nähen? Würden sie ihm Ihr Leben anvertrauen? Davor schützt uns zum Glück die Ärztekammer. Programmieren aber gilt als niedere Tätigkeit, die man am besten möglichst weit weg schiebt, zum Beispiel nach Indien. Diese Missachtung der Programmierkunst ist ein fataler Irrtum, wie ich denke, der unsere Volkswirtschaft Milliarden Euro jedes Jahr kostet.

Sollte der „Certified Scrum Developer“ implizites Wissen wirklich abdecken, könnte er tatsächlich eine Qualifikation transportieren. Sollte er das nicht leisten, wäre es ein weiterer Versuch, den Markt zu segmentieren in Zertifizierte und Ent-Zertifizierte. Darüber hatten Johannes Link und ich uns ja schon Gedanken gemacht. Das wäre schade, war die Agile Bewegung doch einst als innovativer Gruppenprozess gestartet.

GI Fachgruppe „Vorgehensmodelle“ unterstützt agile Vorgehensweisen

Als ich im April 2001 einen Vortrag für die GI Fachgruppe „Vorgehensmodelle“ über agile Verfahren hielt, war die Stimmung noch sehr geteilt: Neben vereinzelter Zustimmung war die Mehrheit der Teilnehmer eher skeptisch — um das mal vorsichtig zu formulieren.

Mittlerweile scheint sich das geänder zu haben, wie aus einer aktuellen Pressemitteilung der Fachgruppe zum 16. Jahresworkshop hervorgeht: „In der Praxis versprechen vor allem die Verwendung agiler Ansätze bei der Projektdurchführung mehr Effizienz und Effektivität. Allerdings waren sich alle Teilnehmer einig, dass in sicherheitskritischen Bereichen aus Gründen der Durchgängigkeit und Nachvollziehbarkeit Formalismen bei der Durchführung von IT-Projekten einzuhalten sind.“

Ich denke, es ist ein schöner Erfolg für die agilen Verfahren, wenn nun auch die GI sie zunehmend unterstützt. Nicht unterschätzen sollte man allerdings den Aufwand zu ihrer Einführung. Die notwendige Umgestaltung der Organisation bei „laufendem Motor“ braucht mehr Erfahrung und Fingerspritzengefühl, als man durch die Lektüre einiger Bücher oder den Besuch eines zweitägigen Seminars erwerben kann, unabhägig davon, wie eindrucksvoll sich das „Zertifkat“ anhört, das man am Ende überreicht bekommt. Erfahrene Unterstützung zahlt sich hier aus.