Archiv der Kategorie: Management

Gunter Dueck über den Stand der Kunst

Veröffentlicht am von

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…

Videocast zu Einführung agiler Entwicklung

Veröffentlicht am von

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.

Jazz nur in „Mini-Fassung“ frei verfügbar

Veröffentlicht am von

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.

Warum Auftraggeber agil sein sollten

Veröffentlicht am von

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.

Cutter Report „Fostering Innovation on the Agile Frontier“

Veröffentlicht am von

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.

Gedanken zur Ressourcenplanung

Veröffentlicht am von

Gestern hat Siemens eine Gewinnwarnung über 900 Mio Euro veröffentlicht. „In der Vergangenheit habe man sich mit Großaufträgen übernommen und mehr Aufträge angenommen, als der Konzern abarbeiten konnte“ berichtet die Süddeutsche Zeitung in ihrer heutigen Ausgabe über ein wichtige Ursache für die Warnung (SZ vom 18.3.2008, S. 19). Sich mit Aufträgen zu übernehmen gehört sicher zu den häufigsten Managementfehlern in Unternehmen jeder Größe. „Droht“ ein Kunde mit einem Auftrag und stellt auch noch Bezahlung dafür in Aussicht, ist die Versuchung groß, sich die internen Kapazitäten und ihre Auslastung schön zu rechnen. Trifft das auf eine Kultur, in der Risikobewusstsein als mangelnde Einsatzbereitschaft fehlgedeutet wird („Das müssen Sie als Chance begreifen“) und wird der Vertrieb mit Provisionen „motiviert“, die ignorieren, ob das Verkaufte auch geliefert werden kann, ist die Katastrophe schon fast vorprogrammiert.

Wer Software erstellt, kann agile Planung einsetzen, um dieses Risiko zu vermindern: Weiterlesen →

Ideen zu Mini-Retrospektiven

Veröffentlicht am von

Nicht immer ist eine vollständige Retrospektive das Mittel der Wahl: Der Aufwand ist beträchtlich und daher oft zu groß, um jeden Monat eine Retrospektive zu machen. Ilja Preuß stellt in seinem Blog-Eintrag A Lightweight Appreciative Retrospection eine Kurzvariante vor, die mit wenigen Stunden auskommt. Ich habe diese Variante selbst noch weder erlebt, noch ausprobiert, die Beschreibung klingt aber vielversprechend.

Natürlich ersetzt eine Mini-Retrospektive keine „große Retrospektive“ in regelmäßigen Abständen, aber für kleine Projekte, oder als „Zwischen-Retro“ ist sie durchaus eine Überlegung wert.

Video über Standup Meetings

Veröffentlicht am von

Thomas Lieder hat ein schönes Video ausgegraben, in dem Stacia Broderick, Boris Gloger, Denise Vielehr, Hubert Smits, Jens Ostsergaard und Tamara Sulaiman vormachen, wie man ein Standup keinesfalls durchführen darf. Freundlicherweise haben sie die Regeln, nach denen es ablaufen sollte auch gleich mitgeliefert. Das sind 8 1/2 Minuten, die sich durchaus lohnen. Viel Spaß:

(Falls der Link bei Ihnen nicht funktioniert, gehen Sie bitte direkt auf http://www.youtube.com/watch?v=B3htbxIkzzM).

Statistiken zu agilen Projekten

Veröffentlicht am von

In seinem jüngsten Eintrag im Cutter-Blog „If Agile Were to Go Mainstream“ fasst der Cutter Metrikexperte Michael Mah seine Auswertungen über agile Projekte zusammen, die er aus seiner über 7400 Projekte umfassenden Projektdatenbank erstellt hat. Zu den interessantesten Schlussfolgerungen zählen meines Erachtens:

  • Die meisten agilen Projekte waren überdurchschnittlich schnell: Etwa 80% lagen über dem Industriedurchschnitt, einige sogar doppelt so schnell, wie traditionelle Projekte. Umgekehrt heißt dass natürlich auch, dass 20% langsamer waren, als der Durchschnitt.
  • Agile Teams waren überdurchschnittlich groß, allerdings stieg die Fehlerquote nicht, wie bei traditionellen Projekten, mit der Teamgröße. Die Neigung zu größeren Teams überrascht mich und steht im Gegensatz zu meiner persönlichen Erfahrung. Ob das kulturelle Unterschiede sind, also der deutschsprachige Raum insgesamt eher zu großen Projekten neigt, ob meine Erfahrung da nicht repräsentativ ist, oder ein Missverständnis vorliegt, ist eine spannende Frage.
  • Agile Projekte haben niedrigere Fehlerraten. Am besten schneiden gut eingespielte XP Teams ab, deren Fehlerraten zum Teil um 30-50% unter dem Industriedurchschnitt lagen. Damit wird die Behauptung gestützt, testgetriebene Entwicklung trage wesentlich zur technischen Qualität eines Produkts bei.

Den vollständigen Artikel – mitsamt einem launigen Aufmacher zum Ursprung agiler Verfahren – finden Sie hier.