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 »

11.7.2008 von Jens Coldewey.

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:

• Bend Schiffer
• Boris Gloger

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

Geschrieben in Scrum, Buchtipp, Agilität | 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 »

14.3.2008 von Jens Coldewey.

Nach längerer Zeit nun der zweite Teil meiner Serie über agile Prakitken. Bisher finden Sie in dieser Kategorie die folgenden Einträge:

• Neue Serie: Agile Praktiken
• Praktiken I: Retrospektiven

Der zweite Teil beschäftigt sich mit automatisierten Akzeptanztests:

Auch agile Entwicklung startet mit den fachlichen Anforderungen. Allerdings werden sie direkt als Akzeptanztests aufgeschrieben, statt in Anforderungsdokumenten. Akzeptanztests sind fachliche Beschreibungen dessen, was das System können soll und zwar so, dass sie automatisch ausgeführt werden können. Automatisch ausführbare Tests steuern die Anwendung und überprüfen deren Ergebnisse ohne menschlichen Eingriff. Der Weg zu diesen Akzeptanztests ist noch eher uneinheitlich, man geht aber in der Regel von den geplanten geschäftlichen Abläufen aus (siehe dazu auch “Use Cases oder User Stories“).

Den Rest des Eintrags lesen »

Geschrieben in Praktiken, Werkzeuge, Testgetriebene Entwicklung, Buchtipp, Agilität | Drucken | Keine Kommentare »

25.1.2008 von Jens Coldewey.

Zu den - neuen - Kerngedanken agiler Entwicklung gehört die Idee, den Prozess in die Verantwortung des Teams zu geben. Das entspricht zum einen dem agilen Manifest, das ja fordert, dass “Individuen und Interaktion wichtiger sind, als Prozesse und Werkzeuge”. Zum anderen wird hier einmal wieder ein Konzept aus dem “Lean Management” umgesetzt: Bei Toyota haben die Arbeiter in der Produktion erheblichen Einfluss auf die Produktionsprozesse. Schließlich wissen sie am besten, was gut funktioniert und was nicht.

Die Verantwortung für den Prozess zu bekommen bedeutet freilich nicht, dass jeder tun und lassen kann, was er will. Das Team muss vielmehr definieren, wie es arbeitet und diesen Prozess ständig verbessern. In seinen Crystal Methoden hat Alistair Cockburn die “Methodology Shaping Workshops” nach jeder Auslieferung als eine der wenigen bindenden Praktiken definiert. Seitdem vor sieben Jahren Norm Kerths Buch “Retrospectives” erschienen ist (siehe unten), haben sich Retrospektiven in allen agilen Verfahren als zentrale Praktik entwickelt: Regelmäßig stattfindende Workshops, auf denen alle Beteiligten reflektieren, wie das letzte Release gelaufen ist und beschließen, was in Zukunft anders gemacht werden soll. Es handelt sich dabei um eine Reflexion der gelebten Projektpraxis, also nicht um ein Review eines Prozessdokuments und auch nicht um einen Audit.
Den Rest des Eintrags lesen »

Geschrieben in Praktiken, Buchtipp, Agilität | Drucken | 1 Kommentar »

9.1.2008 von Jens Coldewey.

Seit Anfang Januar ist die Erstausgabe des Magazins “Business Technology” erhältlich, einem Magazin für oberes und mittleres IT-Management. An der Jungfernausgabe habe ich mit einem Artikel über “Geschäftsausrichtung der IT und moderne Entwicklungsverfahren” mitgewirkt. Aus der Einführung:

IT muss sich heute konsequent an den Erfordernissen der Geschäftsstrategie ausrichten. Die Fähigkeiten von Software dürfen nicht die Gestaltung der Geschäftsprozesse bestimmen. Software-Entwicklung muss schnell und agil veränderten Geschäftsprozessen folgen.

Den vollständigen Artikel können Sie entweder in der Druckausgabe lesen, oder in der Online-Ausgabe.

PS: In einer Einführungsaktion des Software&Support Verlages kann man bis zum 10.2.2008 ein Gratisabo bestellen.

Geschrieben in Management, Buchtipp | Drucken | Keine Kommentare »

27.11.2007 von Jens Coldewey.

Programmiersprachen spielen keine wesentliche Rolle habe ich einst gelernt, es kommt vor allem auf die Qualität der Entwickler an. Diese Aussage stammt aus den frühen 80er Jahren, als Barry Boehm sein “Software Engineering Economics” veröffentlicht hat. Und tatsächlich kann die beste Programmiersprache der Welt wenig ausrichten, wenn das Team inkompetent ist - und ein kompetentes Team wird auch mit altertümlichen Programmiersprachen noch etwas ausrichten können. Also alles in Butter? Gebt mir eine turingvollständige Sprache und ich wuppe Euch das Projekt? Wohl kaum.

Nur in wenigen Bereichen hat sich so viel in den letzten 25 Jahren verändert, wie bei Programmiersprachen und ihren Entwicklungsumgebungen. In den frühen 80ern hatte man im Wesentlichen noch die Auswahl zwischen C, COBOL, Pascal, PL/I und Assembler und bei den Entwicklungsumgebungen die Wahl zwischen vi, emacs und dem Host-Editor. Heute führen die Unterschiede zwischen den verschiedenen Sprachen und Umgebungen durchaus zu Produktivitätsunterschieden von einer Größenordnung, also um den Faktor 10; beim gleichen Team, wohlgemerkt.

Besonders fallen mir diese Unterschiede auf, wenn ich - wie heute einmal wieder - einem Kunden beim Umbauen einer C++ Anwendung helfe. Zur Erinnerung: C++ war der Versuch, dem guten alten C einige Konzepte überzustülpen, die bei flüchtiger Betrachtung als objektorientiert verkauft werden konnten. “Die C-Programmierer müssen dann nicht umlernen” war die häufigste Begründung für diese Sprache. Ohne das belegen zu können, vermute ich, dass genau dieser Umstand - unreflektierter Einsatz objektorientierter Techniken von Programmierern, die nur in prozeduraler Programmierung ausgebildet sind - zu den häufigsten technischen Gründen für gescheiterte Projekte zählt.
Den Rest des Eintrags lesen »

Geschrieben in Refactoring, Buchtipp, Agilität | Drucken | 4 Kommentare »

27.11.2007 von Jens Coldewey.

Hinweis: Die Links zu den Buchtipps in diesem Blog verweisen im Rahmen des Amazon.de Partnerprogramms auf die entsprechenden Bücher bei Amazon.de

Geschrieben in Buchtipp, Allgemein | Drucken | Keine Kommentare »