Archiv der Kategorie: Agilit

Ist Agile Entwicklung billiger II

Veröffentlicht am von

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:

Ist agile Entwicklung billiger?

Veröffentlicht am von

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…

Gunter Dueck zur Konstruktion von Prozessleichen

Veröffentlicht am von

Auch auf die Gefahr hin, dass mein Blog zu einer Dueck-Fanseite verkommt: Der aktuelle Daily Dueck ist einfach zu gut! Gunter Dueck vergleicht die Konstruktion eines neues Geschäftprozesses mit dem Zusammenbau von Leichen in Frankensteins Labor — und kann die Metapher erschreckend weit treiben!

Lasst Prozesse wachsen und konstruiert sie nicht an der virtuellen Powerpointmaschine, ist seine Nachricht. Und dass das Zeit und Geduld erfordert, wie das Aufwachsen von Kindern.

Richtig verstandene Agilität nutzt dazu Retrospektiven. Leider gibt es immer mehr falsch verstandene „Agile Prozesse“, die genau diesen Aspekt vergessen und eben einen „agilen“ Prozess konstruieren wollen. Die Versuchung ist enfach zu groß. Gunter Duecks Polemik verdeutlicht sehr schön, wo das endet:

Gunter Dueck: „Konstruktion von Prozessleichen und das Fehlen von Blut und Atem„

XPDays in Hamburg: Eintägiger Workshop „Agilität erleben“

Veröffentlicht am von

Ich freue mich, im November gemeinsam mit Bernd Schiffer und Henning Wolf von it-agile im Rahmen der XP Days in Hamburg einen eintägigen Workshop „Agilität erleben“ anbieten zu können. Der Workshop ist vor allem für jene gedacht, die sich Agilität bisher eher vorsichtig genährt haben, oder sich nur aus Büchern, Zeitschriften und Blogs informiert haben und nun „gefahrlose Praxis“ suchen; und für jene, die bisher nur agile Entwicklungspraktiken einsetzen und jetzt ihre Leistung auch „auf die Straße“ bringen wollen.

Einen Tag lang haben Sie die Gelegenheit, die wichtigsten Praktiken agiler Teamarbeit und agilen Projektmanagements am eigenen Leib zu erleben – in einer „Entwicklungsumgebung“, die Sie unter Garantie beherrschen. Wir haben den Tag vollständig powerpointfrei gestaltet, schließlich sollen Sie Agilität erleben und nicht von uns überredet werden.

Was werden Sie erleben?

  • Agile Planung
  • Agiles Anforderungsmanagement
  • Querschnittsteams vom Fachexperten bis zum Tester
  • Entwicklung nach Nutzen
  • Agiles Controlling
  • Retrospektiven

Innerhalb eines Tages kann man natürlich nicht nach den Sternen greifen, aber wir versprechen Ihnen ein paar bleibende Eindrücke — und dass wir garantiert innerhalb unseres Sonnensystems bleiben…

Der Workshop findet am Donnerstag, 27.November 2008 in Hamburg statt. Weitere Informationen und die Anmeldung finden Sie auf den Webseiten der XP Days 2008: http://www.xpdays.de/2008/sessions/praxis_erleben.html. Frühzeitige Anmeldung lohnt sich: Die Teilnehmerzahl ist begrenzt!

PS: Wer Ende November keine Zeit hat, nach Hamburg zu kommen, oder keinen Platz mehr bekommet, hat im Januar auf der OOP 2009 in München noch eine zweite Gelegenheit. Ich werde den Workshop separat ankündigen, sobald das OOP-Programm veröffentlicht ist.

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.

Surftipp: Der Procuct Owner in größeren Teams

Veröffentlicht am von

Einen sehr schönen Beitrag zur Agile 2007 haben Mike Lowery und Marcus Evans von der BBC zum Thema „Scaling Product Ownership“ verfasst. Sie beschreiben die Schwierigkeiten, die ihr 90-köpfiges Team durchlitt, bevor es die richtige Organisation für ihren fachlich Verantwortlichen („Product Owner“) gefunden hatte. Nicht nur die Ergebnisse sind interessant; auch der Weg ist typisch für agile Teams: Ausprobieren, scheitern, anders probieren, besser scheitern und schließlich doch einen guten Weg finden. Zwanzig Leseminuten, die sich lohnen.

Scrum Gathering in München

Veröffentlicht am von

Heute war Scrum Gathering in München, des mitterweile jährliche Treffen der Scrum-Anhänger in Deutschland. Ich bin zwar selbst kein Scrum Enthusiast (auch wenn ich gerne die ein oder eine Scrum-Praktik verwende), dennoch wollte ich die Gelegenheit nicht verpassen. Das Treffen war als Open Space organisiert und ich möchte ein paar für mich interessante Themen und Eindrücke wiedergeben.

Was mir gut gefallen hat: Ein guter Teil der Sessions beschäftigte sich weniger mit Scrumpraktiken, sondern mit allgemeiner Teambildungs- und Coachingtechnik. Besonders Hans-Peter Korn hat sich mächtig ins Zeug gelegt, um lösungsbasierte Coachingansätze zu demonstrieren und vor vereinfachenden Modellen zu warnen: Teams und Projekte sind nicht kompliziert (und damit anlysierbar und steuerbar), sondern komplex (und damit weder analysierbar noch steuerbar). Sein Plädoyer: Ihr könnt komplexe Systeme beobachten, Ihr könnt versuchen, sie zu beeinflussen. Aber wenn man anfängt, Modelle einzusetzen, um sie zu analysieren, dann läuft man Gefahr, dass man nur noch das sieht, was ins Modell passt — und Wichtiges übersieht oder falsch interpretiert. Das erinnerte mich doch stark an meinen alten Artikel von 2002: „Manchmal ist mehr drin, als man glaubt – Agile Entwicklung und Emergenz“ und mein Lieblingsbuch zu dem Thema: „Emergence“ von John Holland, das sich mit komplexen Systemen beschäftigt, als Systemen, die Verhalten zeigen, das sich nicht durch Analyse erklären lässt (was nichts mit komplizierten Systemen zu tun hat: Das gute alte Life-Spiel ist ein aus drei primitiven Regeln aufgebauter zellulärer Automat, dessen komplexes Verhalten sich nicht aus den Regeln ableiten lässt!).

Bernd Schiffer stellte in einem ganz interessanten Vortrag das Tuckman Modell zur Gruppenbildung vor (Forming, Storming, Norming, Performing, Re-Performing) und diskutierte dies im Rahmen agiler Teams. Lesenswert, die Folien finden sich hier (Bernds Buchtipp: Eberhard Stahl, „Dynamik in Gruppen: Handbuch der Gruppenleitung“).

Ein Workshop zum Thema Schätzen hat bei mir den Eindruck hinterlassen, dass doch noch deutlich mehr Unsicherheit bei agiler Planung besteht, als ich dachte. Das bedeutet für mich, agiles Schätzen und Planen als nächstes in meiner „Praktiken-Serie“ anzusprechen.

Leider verpasst habe ich einen gemeinsamen Vortrag von Simon Roberts und Christian Schmidkonz, die über die Scrum-Einführung bei der Allianz bzw. SAP berichtet haben – zwei sehr spannende Vorhaben derzeit in Deutschland, die beide schon erfreulich weit gediehen sind.

Nicht ausräumen konnte ich meinen Eindruck, dass manche führenden Köpfe der Scrum Community eher Abstand zu der restlichen agilen Gemeinschaft suchen. Wir alle müssen daran arbeiten, dass hier kein Konkurrenz- oder gar Verdrängungswettbewerb gestartet wird, der nicht nur eine Menge Potenzial vergibt, sondern letztlich beide Seiten sogar schwächt, sondern dass die sehr guten Beiträge beider Seiten gewürdigt und dem gemeinsamen Ziel unterstellt werden: Softwareentwicklung besser, sicherer, wirtschaftlicher und vor allem menschlicher zu gestalten. Als kleiner Lichtblick: Einige der führenden Scrum-Leute sehen durchaus den Bedarf, gemeinsam zu agieren, so dass ich auf einen konstruktiven Dialog unter den Pragmatikern hoffe – und auf Ideen, die vor allem der gemeinsamen Sache helfen. Ich werde dazu beitragen, was ich beitragen kann.

Weitere Berichte zum Scrum Gathering:

Und dann gibt es noch die offizielle Web-Seite: http://scrumaufdeutsch.pbwiki.com/

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.