8.11.2008 von Jens Coldewey.

Schon seit den XPDays 2006, als Martin Heider einen Vortrag über Klinsmanns Leistung bei der Fußball WM und seine Techniken zu Teambildung gehalten hat, wollte ich darüber schreiben. Jetzt ist mir Katja Roth “zuvorgekommen” mit ihrem lesenswerten Blogeintrag “Erfolgreiches Change-Management - Was wir von Klinsmann lernen können“. Viel Spaß beim Lesen!

Geschrieben in Surftipp, Management | Drucken | Keine Kommentare »

6.11.2008 von Jens Coldewey.

Roland Berger hat in der Studie “Be flexible - How engineered products companies prepare for the downturn” 500 Maschinen- und Anlagenbauer untersucht, wie sie mit wirtschaftlichem Abschwung umgehen und Krisen überleben. Als zyklische Branche ist gerade die Investitionsgüterindustrie besonders anfällig für konjunkturelle Schwankungen. Das Resümee: Die besten Unternehmen können so flexibel auf die Krise reagieren, dass sie Konjunktureinbrüche sogar als Chance nutzen können, ihre eigene Marktposition zu stärken.

Wie die meisten anderen Sparten steigt der Anteil der IT an der Wertschöpfung auch im Maschinen- und Anlagenbau stetig. Die von Berger postulierte Flexibilität setzt unter anderem auch entsprechende Flexibilität in Forschung und Entwicklung voraus, nicht nur, aber auch bei der IT. Verfahren und Vorgehensmodelle, die zu Laufzeiten von vielen Jahren führen, können da schnell zum Ballast werden.

Agile Verfahren erlauben hier viel größere Flexibilität. Agile Planungstechniken fügen sich elegant und nahtlos in eine szenariobasierte Unternehmensplanung ein, wie sie Berger bei den erfolgreichen Unternehmen beobachtet. Zu Beginn der Rezession könnte noch ausreichend Zeit bleiben, flexibler zu werden.

“Machen Sie Flexibilität zur Sache des Top-Managements” zählt Roland Berger als einen der fünf strategischen Bausteine auf, um die Krise zu überleben. Diese Forderung dürfte nicht nur für den Maschinenbau gelten.

PS: Mehr über agile Planungstechniken erzähle ich u.a. auf den XPDays 2008 in Hamburg oder auf der OOP 2009 in München

Geschrieben in Planung, Management, Agilität | Drucken | Keine Kommentare »

8.10.2008 von Jens Coldewey.

Felix Rüssel schreibt in seinem “Armer Kater” Blog zu meinem Artikel “Ist Agile Entwicklung billiger?”:

Jens schreibt jedoch auch, dass Kundenzufriedenheit das Primärziel bei jedem Projekt sein sollte. Dem kann ich nicht zustimmen, da dies eine verkürzte Sicht darstellt, v.a. wenn es sich um Unternehmen handelt, die mit Projekten Geld verdienen müssen.

Primärziel einer Unternehmung ist es weiter zu existieren und dabei möglichst Gewinn zu erwirtschaften.

Die Kundenzufriedenheit ist in den meisten Fällen ein wichtiger Faktor, um diese Ziele in einem umkämpften Markt zu erreichen – nicht jedoch das Primärziel!

Um diesen Widerspruch aufzulösen, könnte es helfen, drei Ebenen zu differenzieren:

• Das Ziel eines (Wirtschafts-)Unternehmens ist es natürlich, am Markt zu bleiben und möglichst auch noch Gewinn abzuwerfen (in dieser Reihenfolge! Wozu die umgekehrte Priorisierung führt, erleben wir gerade recht schmerzhaft). Es gibt natürlich auch noch Organisationen, die andere Ziele verfolgen, z.B. öffentlicher Dienst, gemeinnützige Organisationen, Parteien, usw.
• Der Existenzgrund einer Organisation muss aber deutlich spezifischer sein — ein Apsekt, den viele Unternehmensberater und Anleger und leider auch manche Manager gerne übersehen. Der Existenzgrund eines Unternehmens ist das, was in den USA gerne in möglichst blumige “Mission Statements” gepackt wird. Wenn das nicht nur hohle Phrasen sind (”Wir wollen unseren Kunden den besten Service liefern zwischen hier und und dem Neptun…”), drückt sich in ihm die Klammer über die langfrsitigen Strategien aus. Gute Existenzgründe beziehen das Zusammenspiel zwischen Kunden und Unternehmen mit ein. Schöne Beispiele für Existenzgründe sind “Wir wollen unsere Kunden mit Lebensmitteln versorgen, die so billig sind, wie möglich” oder “Wir wollen eine Lebensmittelversorgung sicher stellen, die unserer Verantwortung gegenüber Kunden, Produzenten und Lieferanten gerecht wird.” Wie man leicht sieht, sind das zwei völlig unterschiedliche, gegensätzliche Geschäftskonzepte, aus denen sich trotz Gewinnabsicht auf beiden Seiten völlig unterschiedliche Unternehmen und Kundenkreise ergeben.
• Das Projektziel, über das ich geschrieben habe, bezieht sich auf ein konkretes Vorhaben. Der Kunde kann hier ein Vertragspartner sein, wie bei Softwarehäusern, oder eine andere Abteilung, wie bei interner Entwicklung (auch beides gleichzeitig ist möglich, wenn auch oft nicht so wahnsinnig zielführend). Man kann jetzt den Projekterfolg sehr unterschiedlich sehen: “Umfang, Budget, Termin und Qualität erreicht” ist die traditionelle Definition, “Kunde mit dem Ergebnis hochzufrieden” ist die agile Definition. Dass die traditionelle Definition besser zu Werkverträgen passt und daher ungeachtet der Probleme mit ihr populär ist, ist schon häufig diskutiert worden.

Der von Felix angesprochene vermeintliche Widerspruch kommt als daher, dass wir über völlig unterschiedliche Ebenen gesprochen haben. Allerdings sind diese Ebenen natürlich gekoppelt. Wenn ich ausschließlich auf kurzfristige Gewinnmaximierung ziele, werde ich versuchen, aus einem Projekt so viel Geld herauszuschlagen, wie möglich, zum Beispiel indem ich es immer weiter aufblase, bis ich 200 billige “Juniorberater” möglichst mit Tagessätzen erfahrener Leute beim Kunden im Einsatz habe. Für solche Organisationen ist Kundenzufriedenheit in der Tat sekundär, sie akquirieren dann oft eher über Beziehungen (sog. Alumni-Netzwerke, was nicht bedeutet, dass jede Firma, die ein solches Netzwerk betreibt, in diese Kategorie gehört!). Unternehmen, die langfristige Kundenbeziehungen aufbauen, werden allerdings den Kundenutzen sehr hoch priorisieren. “Mir ist relativ egal, ob wir in diesem Projekt rote oder grüne Zahlen schreiben, wenn wir hier erfolgreich sind, stehen wir im gesamten Marktsegment sehr gut da” ist eine häufige Aussage von Managern, die so denken. Ich glaube, die zweite Sorte von Organisationen wird eher einen Vorteil aus agilen Verfahren ziehen.

Einer anderen Aussagen von Felix möchte ich aber ganz klar widersprechen:

Für die Erreichung der Primärziele Existenzsicherung/Rentabilität sind die Kosten der entscheidende Faktor

Das ist eine zwar sehr moderne aber dennoch fatale Einengung des unternehmerischen Handlungsspielraums. Eine rigide Kostenkontrolle ist dann sinnvoll und notwendig, wenn ich eine Kostenstrategie fahre. Wer eine Differenzierungsstrategie fährt, oder eine Nischenstrategie, kann oft mit seinen internen Kosten deutlich entspannter umgehen (siehe dazu Buchtipp unten). Gerade wegen der von Felix angesprochenen Probleme, Motivätion und Qualität in die Kostenrechnung zu integrieren, ist es bei solchen Unternehmen oftmals kontraproduktiv, zu sehr auf der Kostenbremse zu stehen. Tom DeMarco diskutiert das ausführlich in seinem “Peopleware” und leitet die Diskussion ein mit einem Memo, das der Vizepräsident von Xerox einst an seine Mitarbeiter verschickte: “It has come to my attention, that some of you, when traveling on expenses, have been traveling economy class. This is a first-class organisation. When you fly on business from now on, you fly first class.” (s. 153) Gut das war in den frühen Siebzigern. Andererseits war genau das die Zeit, in der Xerox die besten Beiträge zur Software geleistet hat (Smalltalk, Maus, Fensteroberfläche,…).

Ist das Zufall? Ich denke, es hat etwas mit Attitüde zu tun. Wer sich nur auf die Kosten konzentriert, bringt damit ein klares Wertesystem zum Ausdruck. Wer, wie der Chef bei Xerox, klar macht, dass ihm die Arbeitsbedingungen der Mitarbeiter so wichtig sind, dass er bereit ist, dafür Geld auszugeben, ebenfalls. Zur Kostenführerschaft passt das erste Wertesystem, zu den anderen Strategien eher das zweite. Leider sind viele erstklassige Unternehmen von ihrem Management in die Mittelmäßigkeit gedrängt worden, indem sie diesen Unterschied nicht beherzigt haben.

Auf die Gefahr hin, mit Standardlektüre zu langweilen, noch schnell die zwei Quellenangaben dazu:

• Michael Porter: Wettbewerbsvorteile, Campus 1996, ISBN 3-593-34144-1 gilt als das Standardwerk zu Marktstrategien
• Tom DeMarco, Timothy Lister: Peopleware, Dorset House 1987, ISBN 0-932633-05-6 sollte man zumindest einmal in seinem Leben gelesen haben

Geschrieben in Kunden, Management, Buchtipp, Agilität | Drucken | Keine Kommentare »

12.9.2008 von Jens Coldewey.

Eine der Standardfragen zu agiler Entwickung lautet: “Können Sie denn nachweisen, dass das billiger ist, als traditionelle Vorgehensweise?”

Der Frage liegt ein interessantes Bild zugrunde, nämlich dass es auf der einen Seite ein Projekt gäbe, also ein definiertes Ergebnis, auf der anderen Seite einen Prozess, der auf einer völlig anderen Dimension steht und das Ergebnis nicht beeinflusst.

Dieses Bild spiegelt die Realität der Softwareentwicklung leider nicht so ganz vollständig wider: Agile Teams entwickeln die fachliche Lösung in enger Zusammenarbeit mit den Fachexperten. Das tun sie nicht, weil sie zu faul oder unfähig wären, Pflichtenhefte, Lastenhefte und Spezifikationen zu schreiben (die meisten Agilisten, die ich kenne, können das deutlich besser, als der Durchschnitt), sondern weil sie überzeugt sind, auf diese Weise ein fachlich und wirtschaftlich besseres Ergebnis zu erhalten.

Das bedeutet auf jeden Fall, dass das Ergebnis anders sein wird, als mit traditioneller Vorgehensweise. Nur die Kosten zu vergleichen, vergleicht also Äpfel mit Birnen. Wer noch dazu Schätzungen vergleicht, statt der Gesamtkosten über die Lebenszeit des Softwaresystems, vergleicht auch noch mit Birnen, deren Bäume noch nicht einmal gepflanzt sind — in der Regel auf Böden, von denen man nicht einmal weiß, ob da Obstbäume überhaupt gedeihen.

Ist das jetzt der Versuch, sich einem “objektiven” Vergleich zu entziehen? Ganz im Gegenteil, wir sollten nur die richtigen Parameter vergleichen: Kundenzufriedenheit, weil das das Primärziel jedes Projekts sein sollte, und Motivation des Teams, weil damit die Investition in Ausbildung und Aufbau des Teams, der Kundenbeziehung und des Wissens geschützt wird. Bei beiden Kriterien schneidet agile Entwicklung in allen mir bekannten Untersuchungen signifikant besser ab, als traditionelle Verfahren (auch wenn es natürlich Ausreißer gibt).

Wem das zu “unwissenschaftlich” ist, der wird nicht um die Mühe herum kommen, zwei Teams an die gleiche Aufgabe zu setzen und unter wirklich vergleichbaren Bedingungen Kosten und Nutzen zu vergleichen. Leider habe ich bisher noch niemanden gefunden, der es dann doch so genau wissen wollte und bereit gewesen wäre, das Geld dafür in die Hand zu nehmen. Und das wäre natürlich auch nur ein einzelnes Projekt, das nicht repräsentativ wäre, und keinerlei “wissenschaftlich fundierte” Aussage zulassen würde…

Geschrieben in Management, Agilität | Drucken | 1 Kommentar »

28.7.2008 von Jens Coldewey.

Gunter Dueck hat an seinen neuesten News das folgende PS angehängt:

Der Homo Oec. soll als nächstes in Koreanisch erscheinen. Ich war verwundert. Warum gerade…? Antwort: Die Koreaner sind “immer” die ersten mit dem Übersetzen, weil die Fachleute dort einfach immer genau den state-of-the-art wissen wollen. Sehen Sie die Unterschiede zu den neuen Kulturen?

Dueck legt hier meiner Ansicht nach den Finger in eine unserer gefährlichsten Wunden: Es ist nicht Teil unserer Kultur, immer vorne dabei sein zu wollen, sich immer auf dem Stand der Kunst zu sein. Statt dessen verfolgt jede Generation das jeweilige Dogma ihrer Jugend bis zur Rente - oder Emeritierung. Das hat sein gutes, weil es viel Zeit lässt, die Dinge wirklich zu verstehen. Das Problem ist dabei nur die mangelnde Selbstkritik, die es anderen erlaubt, uns zu überholen. Der Dogmatismus, der sich wirksam darum kümmert, dass die Jüngeren einen nicht überholen. Und der simple Umstand, dass wir so unsere führende Position am Weltmarkt verspielen, auf der unser Wohlstand und der unserer Kinder aufbaut.

Erinnern Sie mich bitte an diesen Blog-Eintrag, wenn ich im Jahre 2031 meinen Beitrag “Agile Entwicklung — Warum wir damals schon Recht hatten und alles neuere Mist ist” einreiche…

Geschrieben in Zitate, Management, Politik | Drucken | Keine Kommentare »

25.7.2008 von Jens Coldewey.

Am Rande der OOP 2008 hat mich Damir Tomicic für die Microsoft Architects Connection zur Einführung agiler Entwicklung interviewt. Das Interview ist jetzt als 30-minütiges Videocast verfügbar:

Einführung agiler Entwicklung - Ein Resümee aus 10 Jahren Erfahrung.

Weitere Interviews mit anderen Referenten finden Sie in der OOP 2008 Nachlese der MAC.

Geschrieben in Ankündigungen, Management, Konferenzen, Agilität | Drucken | Keine Kommentare »

24.7.2008 von Jens Coldewey.

Ich hatte im Januar schon einmal kurz über Jazz geschrieben (”Jazz ist nun doch frei verfügbar“), damals in der Hoffnung, IBM würde bei Jazz eine ähnliche Politik verfolgen, wie bei Eclipse und die Projektmanagement-Plattform frei zur Verfügung stellen. Die erste offizielle Version ist jetzt unter dem Namen “Rational Team Concert 1.0″ verfügbar (http://www.jazz.net) und leider hat sich IBM nicht zu dem Schritt durchringen können, die Software mit einer freien Lizenz bereit zu stellen. Immerhin gibt es kostenlose Lizenzen für Open-Source Projekte und akademischen Einsatz. Und es gibt für ganz kleine Teams von höchstens drei Personen eine kostenlose Version “Express-C” zum Herunterladen — kaum die Teamgröße, in der ein solches Werkzeug seine Stärken ausspielt.

Ich finde es schade, dass IBM nicht am Erfolg von Eclipse anknüpft und sich bei Jazz für traditionelle Lizenzpolitik entschieden hat, statt den mutigeren Schritt zu gehen. Ob sich diese Entscheidung für IBM rechnet, ist schwer abzuschätzen; ich neige dazu, das nicht zu glauben. Die Chance, den Markt für Projektmanagementwerkzeuge zu revolutionieren, dürfte IBM so aber kaum wahrnehmen können. Statt dessen nur ein weiteres Produkt unter vielen. Schade eigentlich.

Geschrieben in Werkzeuge, Planung, Management, Agilität | Drucken | 1 Kommentar »

7.7.2008 von Jens Coldewey.

Wenn ich Vorträge oder Workshops zu agilen Geschäftmodellen gebe, lautet eine meiner ersten Fragen an das Publikum “Wer von Ihnen ist eher Auftraggeber?” Meist haben sich ein oder zwei Auftraggeber in das Publikum verirrt, der Rest stammt aus Softwarehäusern, die gerne agil arbeiten wollen, aber “nicht wissen, wie ich meinen Kunden dazu bringe”.

Das erstaunt: Es sollten eigentlich die Auftraggeber sein, die agile Entwicklung einfordern. Sie haben den wesentlichen Nutzen aus den Techniken:

• Sie erhalten regelmäßig lauffähige Software, die bereits früh eingesetzt werden kann. Das verringert das Risiko eines Totalausfalls erheblich und bietet zudem die Chance, bereits während der Entwicklung umzusteuern
• Sie müssen nicht alle fachlichen Inhalte ganz am Anfang festlegen, sondern können sich Optionen offen lassen, bis die Entwicklung an dieser Stelle angekommen ist
• Fachliche Diskussionen laufen am konkreten Beispiel. Ihre Fachexperten müssen nicht in abstrakten Methoden geschult werden, um eingesetzt werden zu können
• Das Controlling ist wesentlich verbessert: Statt vieler grüner Ampeln, die acht Wochen vor Systemstart “überraschender Weise” auf rot schalten, wird Fortschritt in abgenommener Funktionalität gemessen - ein wesentlich zuverlässigeres Maß
• Sie erhalten die aus Ihrer Sicht wichtigsten Teile zuerst und behalten über die gesamte Laufzeit die Kontrolle über das, was als nächstes angegangen wird
• Sie können das Projekt beenden, wenn Sie feststellen, dass die bisher erreichte Funktionalität ausreicht; nicht erst, wenn alles implementiert ist, was Sie sich zu Anfang einmal ausgedacht haben. Das kann die Kosten schon mal um 60 oder 80 Prozent reduzieren

Warum sind dennoch eher wenige Auftraggeber an agile Konzepten interessiert? Ich denke, da kommen verschiedene Gründe zusammen:

• Die Macht der Gewohnheit führt dazu, dass sich viele Auftraggeber längst mit Prozessen arrangiert haben, die sie eher knebeln, als ihnen die nötige Freiheit zu geben. Die internen Strukturen sind an Werkverträge zum Festpreis angepasst. Andere Formen benötigten andere Strukturen, die erst aufgebaut werden müssten
• Die Vorstellung, Individualsoftware sei als “Gewerk” behandelbar, das einmal spezifiziert nach definierter Zeit “frei Bordsteinkante” geliefert wird, hält sich hartnäckig vor allem unter fachfremden Entscheidern, wie Juristen und Betriebswirtschaftlern. Hier ist es uns noch nicht gelungen, das notwendige Problembewusstsein zu schaffen. Zudem fehlen bisher Standard-Vertragsmodelle, um agile Entwicklung abzudecken — auch wenn es durchaus vielversprechende Ansätze gibt
• Gängige Risikobewertungen unterschätzen häufig die enorme Kosten, die von scheiternden strategischen Projekten ausgehen ebenso, wie die Wahrscheinlichkeit, dass der GAU eintritt. Zur Risikoabwehr werden Vertragsklauseln bemüht. Das verkennt, dass solche Klauseln höchstens die direkten Kosten auf den Vertragspartner abwälzen — kein Trost, wenn man selbst wegen Softwareproblemen Konkurs geht oder man den Vertragspartner schon mit einem Bruchteil des Schadens ruinieren würde
• Agile Entwicklung verlangt Entscheidungsfähigkeit auf Seite des Auftraggebers. Nicht jede Organisation kann das gewährleisten
• Last but not least: Wir haben bisher versäumt, auch nicht-technischen Auftraggebern die Ideen agiler Entwicklung nahe zu bringen.

Fazit: Agile Entwicklung ist vor allem für die Auftraggeber interessant, denen am Erfolg ihres Auftrages gelegen ist. Dann lassen sich auch organisatorische Hürden schleifen und Vertragsmodelle gestalten, die die benötigte Flexibilität aufweisen ohne beide Seiten unnötig einzuschränken.

Geschrieben in Kunden, Management, Agilität | Drucken | 2 Kommentare »

26.5.2008 von Jens Coldewey.

Einen sehr nachdenklichen Beitrag hat Gunter Dueck in seinem Daily Dueck zur Gier in Großunternehmen geschrieben, zu dem ständigen Zwang, alles noch schneller zu machen, und zur Rolle der Mitarbeiter in diesem Spiel: Das Schweigen ist Schrei!

Lesenswert.

Geschrieben in Surftipp, Management | Drucken | Keine Kommentare »

1.4.2008 von Jens Coldewey.

Im letzten Jahr habe ich die Ausgaben Mai und Oktober des Cutter IT Journal als Gasteditor herausgegeben. Die Maiausgabe beschäftigte sich unter dem Titel “Exploring the Agile Frontier” mit dem Einsatz agiler Verfahren außerhalb der “Standardprojekte”, also mit verteilten Teams, bei lebenserhaltenden Systemen und in nicht-agilen Organisationen.

Die Oktoberausgabe hatte den Titel “Fostering Innovation: What Role Does Agile Software Development Play?“. Sie enthielt fünf Beiträge zum Zusammenhang zwischen Innovation und Agilität. Die Thesen verliefen von “Agilität behindert Innovation” bis zu “Agilität ist die Geburtshelferin der Innovation”.

Aufgrund der großen Nachfrage hat Cutter nun beide Ausgaben zu dem Report “Fostering Innovation on the Agile Frontier” zusammengefasst.

Geschrieben in Ankündigungen, Management, Buchtipp, Agilität | Drucken | Keine Kommentare »