4.2.2012 von Jens Coldewey.

“The best architectures, requirements, and designs emerge from self-organizing teams” heißt es in den viel zu wenig beachteten 12 Prinzipien des agilen Manifests. Nach mittlerweile mehr als einer Dekade Erfahrung mit agiler Entwicklung wird wohl jeder Praktiker dieses Prinzip bestätigten.

Auf Teamebene ist Selbstorganisation mittlerweile Stand der Kunst. Aber wenn es um eine ganze Organisation geht, betritt man noch immer Experimentiergebiet. Wir versuchen bei it-agile, Selbstorganisation so weit zu leben, wie das möglich ist (siehe dazu auch Stefan Roocks Blog-Eintrag) - eine erhebliche Herausforderung, weil die meisten traditionellen Organisationsformen früher oder später auf hierarchische Strukturen zurückgreifen. Nun ist es das eine, von hierarchiefreien, selbstorganisierten Unternehmen zu träumen, etwas anderes, das wirklich umzusetzen. Zumindest, wenn man die Phase des kleinen Startups verlassen hat, das im wesentlichen auf Zuruf funktioniert.

it-agile gehört zu über 70% den derzeit 33 Mitarbeitern, wodurch die Mitarbeiter rein formal jederzeit einen Gesellschafterentscheid herbeiführen können. Bei den meisten Firmen mischen sich Gesellschafter nur sehr wenig in die operativen Abläufe im Unternehmen ein, weil sie ihre Beteiligung eher als Finanzanlage sehen. Unsere Gesellschafter haben aber deutlich mehr im Spiel: Ihre Entscheidungen beeinflussen nicht nur die Rendite, sondern auch ihre tägliche Arbeit. Sie machen daher munter von ihren Möglichkeiten Gebrauch und fällen Entscheidungen über alle Belange, die ihnen wichtig sind. Das Paradies?

Leider hat auch diese weitreichende Selbstorganisation ihre Schattenseiten. Schließlich müssen sich über 30 erwachsene Menschen auf Lösungen einigen. Das führt dazu, dass Entscheidungen intensiv diskutiert werden, was sie nicht immer beschleunigt.

Damit Selbstorganisation funktioniert, benötigt man unstrukturierte Kommunikationskanäle. In vielen Unternehmen tut eine gemütlich eingerichtete Kaffeeküche da schon gute Dienste, wir arbeiten oft über ganz Deutschland verteilt. Als Kaffeeküchenersatz nutzen wir ein internes Microbloggingsystem, das von der Mehrheit der Mitarbeiter fleißig genutzt wird.

Das reicht in der Regel, um einen großen Teil der Probleme zu artikulieren. Sie zu einer Lösung zu führen, ist deutlich schwieriger. In den letzten Jahren haben wir gelernt, durch den Einsatz von regelmäßigen Open Spaces, World Cafés, Fishbowl Sessions und Retrospektiven auch mit über 30 Mitarbeitern noch zu Entscheidungen zu kommen, aber manchmal braucht das schon eine ganze Menge Moderationstechnik. Vor allem aber haben wir gelernt, nicht mehr nach der großen Lösung zu suchen. Stattdessen bemühen wir uns um kleine Schritte. Statt des großen Veränderungsprojekts setzen wir auf kleine Experimente. Die Chance, für einen Vorschlag eine Mehrheit zu bekommen, ist umso größer, je kleiner die Veränderung ist.

Wenn die Entscheidungen Kunden betreffen, lassen wir uns von den Ideen des Lean Startups leiten und experimentieren mit Kundenumfragen, mit Veränderungen auf der Web-Seite, oder indem wir bei unseren Bestandskunden nachfragen, ob sie Interesse haben, sich an einem Experiment zu beteiligen. Bei internen Fragen ist die Kernfrage immer, “Was ist die kleinste, mögliche Veränderung, um das auszuprobieren?” Oft genug stellen wir dann fest, dass selbst diese “kleine” Veränderung deutlich mehr Dynamik entfaltet, als wir dachten.

Ein schönes Beispiel dafür ist die Einführung der Peergroups: Zunächst war bei uns der Kreis der Seniorberater (zu dem auch die Geschäftsführer gehören) dafür zuständig, Personalgespräche zu führen und über die Einstufung der einzelnen Mitarbeiter zu entscheiden. Mit zunehmender Größe funktionierte das nicht mehr, weil wir immer weniger Einblick in die tägliche Arbeit der Kollegen hatten. Anstatt den üblichen Weg zu gehen und eine Hierarchieebene einzuziehen, wählten wir einen viel kleineren Schritt - zumindest dachten wir das: Jeder Mitarbeiter kann sich drei Kollegen suchen, mit denen er seine Personalgespräche durchführt, von denen einer ein Seniorberater sein musste. Diese Gruppe würde den Mitarbeiter in seiner persönlichen Entwicklung beraten und der Seniorberaterrunde eine Gehaltsempfehlung machen. Im Prinzip vergrößerten wir also das Gremium des Personalgesprächs “nur”.

Nachdem aber fast jeder Mitarbeiter sich plötzlich in einer Peergroup fand und damit ein Stück Verantwortung für die Kollegen übernehmen musste, wurden Fragen der persönlichen Entwicklung plötzlich von einer hierarchischen Angelegenheit zu einer Teamaufgabe. Viele Kollegen wurden damit zunächst auch aus ihrer Komfortzone herausgerissen, insbesondere bei der Diskussion der Gehaltseinstufung. Interessanterweise entsprachen aber bei der nächsten Gehaltsrunde alle Empfehlung der Peergroups auch den Einschätzungen der Seniorberaterrunde. Man war offensichtlich zu gleichen Ergebnissen gekommen. Bei einer Retrospektive nach einem halben Jahr war die Quintessenz eindeutig: Das Feedback war deutlich wertvoller geworden, die meisten empfanden das neue Vorgehen als wesentlich fairer. Einige Kollegen hatten allerdings auch das Gefühl, dass es schwieriger geworden sei, im Gehaltsgefüge aufzusteigen. Niemand, der schon eine Peergroup hatte, zog allerdings die formal noch immer mögliche Option, wieder zum alten Modell zurück zu kehren.

Mittlerweile sind die Peergroups ein fester Bestandteil der Firmenkultur. Was als Experiment gestartet war, wurde durch Selbstorganisation und emergentes Verhalten zu einem zentralen Element unseres Miteinander. Und einzelne Kollegen experimentieren bereits mit den nächsten Schritten: Zum Beispiel laden sie Kunden mit in ihre Peergroups ein, oder experimentieren mit unterschiedlichen Frequenzen. Damit das nicht in einen unkoordinierten Zoo ausartet, treffen wir uns ein- bis zweimal im Jahr zu einem “Peergrouptag”, zu dem neben einer ganzen Serie von Peergroup-Gesprächen auch die gemeinsame Reflexion und Verbesserung des Konzepts gehört, aber ohne einen Zwang zur Einheitlichkeit. Und anschließend gibt es die “Beergroup”.

Für traditionell gesinnte Manager hört sich das an, wie eine Entmachtung der Geschäftsführung und in der Tat treffen die Mitarbeiter/Gesellschafter bei uns viele Entscheidungen, die üblicherweise im Aufgabenfeld der Geschäftsführung liegen, wie zum Beispiel Personalprozesse. Allerdings empfinden wir das nicht als “Machtverlust”, sondern als wesentliche Qualitätsverbesserung. Je größer die Firma wird, umso mehr geht unsere Aufgabe weg vom operativen Management. Stattdessen kümmern wir uns mehr und mehr darum, die Selbstorganisation sicher zu stellen, die Kommunikationskanäle weit genug offen zu halten, arbeits- und selbstorganisationsfähige Einheiten zu ermöglichen und dafür zu sorgen, dass ausreichend unterschiedliche Positionen die Dynamik erhalten. Eine deutlich spannender Aufgabe, als Urlaubsanträge zu genehmigen (was wir übrigens abgeschafft haben). Natürlich fällt nicht jede Entscheidung so aus, wie ich oder mein Kollege Henning Wolf uns das wünschen, aber oft genug ist die gefundene Lösung zumindest ebenbürtig, wenn nicht sogar besser. Und auch, wenn eine Entscheidung mal nicht so gelungen ist, steht die Mannschaft zumindest dahinter und korrigiert sie, statt sie einfach zu unterlaufen.

Ist ein solcher Grad an Selbstorganisation und Emergenz für alle Unternehmen empfehlenswert? Ich denke, nein. Unser Modell basiert meiner persönlichen Ansicht nach auf einigen Voraussetzungen, die so nicht überall gegeben sind:

• Ein tolles Team, das Freude daran hat, eine etwas andere Firma zu gestalten
• Tolle Kunden, die bereit sind, auch mal ungewöhnliche Wege mit uns zu gehen
• Die Doppelrolle als Mitarbeiter und Gesellschafter, die dazu führt, dass die Gewinne nicht in einem Machtpoker zwischen Mitarbeitern und Eignern verteilt werden, sondern jede(r) auch ökonomische Verantwortung hat
• Die Tatsache, dass ein großer Teil unserer Kollegen in Moderation, Reflexion und Selbstorganisation geschult ist und sie diese Techniken auch in der täglichen Arbeit immer wieder einsetzen
• Ein hoher Level gegenseitigen Respekts
• Eine Marktstrategie, die auf Innovationskraft basiert und die notwendigen Spielräume bietet
• Der Mut und die Freude zum Experimentieren
• Eine Firmenkultur, die üblichen Status- und Machtsymbolen wenig bis gar keinen Wert bemisst

Das heißt nicht, dass man nicht auch einen Discounter mit angelernten Kräfte in Selbstorganisation führen kann, nur wird man dafür vermutlich andere Techniken einsetzen müssen.

Geschrieben in it-agile-blog-planet, Management, Agilität | Drucken | 6 Kommentare »

21.1.2010 von Jens Coldewey.

Ab sofort werde ich neben Henning Wolf als zweiter Geschäftsführer in die it-agile GmbH einsteigen und die neue Münchner Geschäftstelle von it-agile aufbauen. Ich freue mich darauf, gemeinsam mit einem Team einiger der besten Agilisten Deutschlands ein aufregendes neues Kapitel in der Firmengeschichte von it-agile und in meiner eigenen Laufbahn aufzuschlagen. Und vor allem freue ich mich darauf, mit exzellenten Kollegen und guten Freunden zusammen zu arbeiten.

Wir werden zunächst München als zweiten Beratungsstandort neben Hamburg aufbauen mit Schwerpunkt agiler Beratung für Süddeutschland, Österreich und Schweiz. Später werden wir hier auch agile Entwicklungsleistungen anbieten.

Die Marke Coldewey Consulting stelle ich zu diesem Zeitpunkt ein, dieser Blog und meine Web-Seiten werden aber als private Seiten weiter bestehen bleiben. Unberührt bleibt meine Zusammenarbeit mit dem Cutter Consortium und meine Tätigkeit als Chefredakteur des OBJEKTspektrum.

PS: Natürlich brauchen wir zum Aufbau der Münchner Geschäftsstelle auch erfahrene Agilist(inn)en, die Lust haben, unser Team zu verstärken! Sprechen Sie/Sprich mich an!

Geschrieben in it-agile-blog-planet, Ankündigungen | Drucken | 4 Kommentare »

22.12.2008 von Jens Coldewey.

Nachdem ich mich in meinem Beitrag “Was ist anders bei agiler Planung” mit den grundlegenden Mechanismen agiler Planung beschäftigt habe, stellte Maximilian Scherf die Frage, “Wie kann ich denn so beurteilen zu welchem Zeitpunkt ich was fertig haben werde?” Die Frage ist sehr berechtigt, aber nicht so einfach zu beantworten, so dass ich hier in einem eigenen Eintrag darauf antworten möchte - zumindest grob.

Grundsätzlich muss man sich darüber im klaren sein, dass eine Terminaussage in einem Softwareprojekt die Vorhersage eines chaotischen Systems ist und damit der Wettervorhersage ähnelt (ich rede hier von chaotischen Systemen im Sinne der Theorie komplexer Systeme, nicht aus der Perspektive von Eltern, die in das Kinderzimmer schauen). Chaotische Systeme zeichnen sich dadurch aus, dass ihr Verhalten umso schwerer vorhersagbar ist, je weiter man in die Zukunft schaut: Die Wettervorhersage für die nächsten fünf Minuten bekommt auch der Laie üblicherweise korrekt hin, für den nächsten Tag müssen selbst Profis erheblichen Aufwand treiben und für mehr als eine Woche sind seriöse Vorhersagen derzeit nicht möglich.

Im Projektmanagement sind die planbaren Zeithorizonte zum Glück deutlich länger: Eine Woche ist meist kein Problem, einen Monat bekommt man auch noch ganz gut hin, ab einem Quartal wird es eng. Eine “genaue” Vorhersage ist daher unmöglich, bei einer “verbindlichen” Zusage muss man schon relativ vorsichtig sein, was man unter welchen Voraussetzungen verspricht. Erlaubt ein Planungsverfahren nur digitale Aussagen darüber, was “geschafft wird”, ist es also unrealistisch und nur wenig brauchbar. Statt dessen braucht man ein Verfahren, das einem zumindest ungefähre Aussagen zur Wahrscheinlichkeit ermöglicht: “So wie dieses Feature derzeit priorisiert ist, wird es mit 80% Wahrscheinlichkeit im nächsten Release enthalten sein”. Genügen einem diese 80% nicht, muss man es eben höher priorisieren - auf Kosten anderer Features, die dadurch weniger wahrscheinlich werden.

Wie kommt man auf Basis agiler Planung zu einer solchen Aussage? Die Basis sind die Schätzungen und die Erfahrungswerte aus den vorigen Iterationen. Die Grafik unten stammt von einem meiner Kunden, also aus einem real existierenden Projekt. In ihr sieht man die aus der Häufigkeitsverteilung abgeleitete Wahrscheinlichkeit, dass innerhalb einer Iteration mindestens n Aufwandspunkte abgeschlossen werden. Man kann aus dieser Kurve zum Beispiel ablesen, dass in mehr als 50% der Fälle mindestens 21 Punkte abgeschlossen wurden, in mehr als 80% der Fälle mindestens 13 Punkte und so weiter. Mit anderen Worten: Ist eine Aufgabe so hoch priorisiert, dass ihr eigener geschätzter Aufwand und der aller höher priorisierten Aufgaben in Summe weniger als 13 Punkte ausmacht, so wird sie in dieser Iteration mit mindestens 80% abgeschlossen werden. Oder noch anders formuliert: Ich kann Aufgaben für bis zu dreizehn Punkte Aufwand für diese Iteration zusagen, wenn mir 80% Erfüllungswahrscheinlichkeit ausreichen. Brauche ich 90%, sollte ich mich auf 10 Punkte beschränken, mit (fast) 100% erreiche ich 8 Punkte und reichen mir 50% so kann ich munter 21 Punkte “versprechen”. Unabhängig von dem, was man versprochen hat, zeigt diese Grafik aber auch, dass man sich auch für den Fall rüsten sollte, dass man deutlich mehr schafft, also ruhig für 42 Punkte Features aufnehmen, auch wenn man ziemlich sicher weiß, dass man das kaum erreichen wird (Die Grafik stammt übrigens aus meinem Vortrag für die OOP 2009).

Kann ich für eine gegebene Aufgabe sagen, mit welcher Wahrscheinlichkeit sie innerhalb der nächsten Iteration fertig wird, so kann ich daraus auch längerfristige Vorhersagen ableiten, allerdings erstmal nur unter der — reichlich unrealistischen — Annahme, dass sich die Priorisierung in der Zwischenzeit nicht ändert. In der Regel ist das aber schon mehr als ausreichend, um zum Beispiel den Umfang des nächsten Releases kommunizieren zu können, ohne sich hinterher zu blamieren.

Für längerfristige Vorhersagen wird aber auch eine solche wahrscheinlichkeitsbasierte Technik zu unrealistisch. Hier kann man wieder Anleihen in der Meteorologie nehmen, diesmal in der Klimavorhersage. Dort wird nicht mit einem Modell gearbeitet, sondern es werden verschiedene Szenarien unter verschiedenen Annahmen berechnet, aus denen sich ein Korridor ergibt. Aber das würde jetzt den Umfang eines Blogeintrags endgültig sprengen.

Aufmerksame Leser werden jetzt anmerken, dass ich Maximilian Scherfs Frage eigentlich gar nicht beantwortet habe: Mit diesen Techniken kann man nämlich erstmal nur Vorhersagen darüber treffen, welche Features ich zu einem gegebenen Zeitpunkt wahrscheinlich fertig haben werde, nicht aber, wann ein gegebenes Feature fertig sein wird. Auch wenn der Unterschied subtil ist (und in den meisten Kontexten ohne Bedeutung), reflektiert das eine Grundidee iterativer Entwicklung: Die Termine stehen fest, gedreht wird am Umfang.

Das ist zwar unbequemer, als das übliche “Termine und Umfang stehen fest”, aber dafür erspart man sich das ebenfalls übliche Drehen an der Qualität, um die Zusage einzuhalten. Schlechte Qualität ist schließlich ein Selbst- und Fremdbetrug, der für alle Beteiligten sehr teuer ist. Zwar kann man auch bei agiler Planung darauf bestehen, dass bestimmte Features zu bestimmten Terminen fertig sind, aber eben nicht mehr, als erfahrungsgemäß realistisch sind. Also in unserem Beispiel für nicht mehr als 8 Punkte pro Iteration. Das ist zwar nicht immer bequem für die Verantwortlichen, aber realistisch. Und Management auf Basis unrealistischer Annahmen sollte angesichts der derzeit in der Weltwirtschaft zu besichtigenden Folgen nur noch von wenigen mit “durchsetzungstarkem Management” verwechselt werden und damit verdienter Maßen und endgültig wieder aus der Mode kommen.

Geschrieben in it-agile-blog-planet, Praktiken, Planung, Management, Agilität | Drucken | 2 Kommentare »

8.12.2008 von Jens Coldewey.

Dass Refactoring in Java mit Eclipse so richtig Spaß macht und auch die Kombination von Visual Studio mit Resharper oder DevExpress ganz brauchbar ist, dürfte zumindest unter Agilisten hinreichend bekannt sein. PHP-Entwickler haben es da deutlich schwerer, wie Roy Ganor in seinem Blog-Eintrag “Refactoring PHP Code” beschreibt. Zend scheint zumindest ein paar Basisfunktionen anzubieten, aber selbst der Beitrag (auf dem Firmenblog!) klingt nicht wirklich enthusiastisch. Dennoch kann es sich für PHP-Entwickler lohnen, hineinzuschauen und zumindest zu beobachten, was dort die nächste Zeit passiert.

Achtung: Ich selbst habe keinerlei Erfahrung mit Refactoring unter PHP! Wer da mehr weiß, ist herzlich eingeladen, hier Kommentare zu ergänzen.

Geschrieben in it-agile-blog-planet, Surftipp, Werkzeuge, Refactoring, Agilität | Drucken | Keine Kommentare »

1.5.2008 von Jens Coldewey.

Will man einmal richtig Spaß haben, so werfe man in eine Gruppe von “Agilisten” und “Traditionalisten” das Stichwort “Architektur”: Als hätte man ein Zündholz in einen Strohhaufen geworfen entflammt sofort eine äußerst emotionale Diskussion, deren Randbereiche zwei Statements markieren: “Ohne eine saubere Anfangsanalyse und solide Anfangsarchitektur kommt kein ernsthaftes Projekt aus” und “Wir brauchen keinen Architekten, die Architektur entsteht beim Programmieren”. Zwischen diesen beiden Extremen findet man fast jede denkbare Zwischenposition.

Ich habe viele dieser Diskussionen verfolgt und bin mittlerweile zu dem Schluss gelangt, dass hier mindestens drei verschiedene Themen munter durchmischt werden:

• Wann wird die Architektur erstellt? Ist die Architektur eine eigene Phase zu Projektbeginn, wird sie zu Beginn jeder Iteration erstellt, oder entsteht Sie während des Programmierens durch Refaktorisieren?
• Wie wird die Architektur repräsentiert? Existiert ein eigenes Dokument oder repräsentiert der Code die Architektur — wobei dann oft Werkzeuge eingesetzt werden, um grafische Darstellungen aus dem Code zu extrahieren und wichtige Eigenschaften zu prüfen, zum Beispiel automatisierte Test, um Abhängigkeiten zu prüfen.
• Wer ist für die Architektur verantwortlich? Gibt einen oder mehrere Architekten? Als Entscheider oder als Moderatoren? Oder ist das Entwicklungsteam gemeinsam verantwortlich?

Ich denke, auf welche “Seite” man sich bei diesen drei Fragen schlägt, hängt entscheidend von der Frage ab, was man sich von der Architektur erwartet. Die Antwort darauf wird oft stillschweigend als “selbstverständlich” vorausgesetzt, ohne zu sehen, dass dort der eigentliche Konflikt liegt:

In traditioneller Sicht soll die Architektur Änderungen an bestehendem Code vermeiden. Sie sollte also so flexibel sein, dass zukünftige oder absehbare Anforderungen möglichst schon abgedeckt sind und ohne Änderungen an bestehendem Code oder zumindest der Architektur implementiert werden können. Architektur versucht die zukünftige Entwicklung vorauszusehen.

In agiler Interpretation soll Architektur Änderungen des Codes und ihrer selbst ermöglichen. Eine gute Architektur kann schnell an neue funktionale und nicht-funktionale Anforderungen angepasst werden. Sie ermöglicht möglichst viele zukünftige Entwicklungen. Änderbarkeit ist daher das Leitmotiv agiler Praktiken wie einfaches Design, testgetriebene Entwicklung, Refaktorisieren und Redundanzvermeidung.

Steht man auf dem Standpunkt, Änderungen an der Architektur seien schlecht und zu vermeiden, so wird man fast zwangsläufig zu dem Ergebnis kommen, dass die Architektur vor der Realisierung von einem starken Architekten erstellt werden müsse und daher nicht im Code repräsentiert werden kann.

Sieht man Änderungen als willkommenes Designwerkzeug, kann man die drei Fragen deutlich entspannter angehen. Die Antworten können sich nach anderen Faktoren richten, wie Kritikalität, Team- und Führungskultur und Erfahrung in der Domäne. Fast alle Kombinationen sind hier möglich; viele von ihnen auch in bestimmten Situationen sinnvoll.

In meinen Projekten kamen einige Teams ohne Architekten aus, andere ernannten irgendwann ein Mitglied zum Hüter der Architektur. Immer waren durch Refaktorisieren entstehende Architekturen in fast allen Qualitätsmerkmalen den zu Beginn erstellten Architekturen deutlich überlegen — und dazu auch noch wesentlich billiger. Zudem halte ich mir gerne Optionen offen.

Geschrieben in it-agile-blog-planet, Software Design, Refactoring, Agilität | Drucken | 2 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, it-agile-blog-planet, 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 it-agile-blog-planet, Praktiken, Buchtipp, Agilität | Drucken | 1 Kommentar »

20.12.2007 von Jens Coldewey.

Refactoring von Spaghetticode ist grundsätzlich anders, als Refactoring im Rahmen testgetriebener Entwicklung: Letzteres ist gut verstanden und bedarf keiner besonderen Beachtung während der Planung, die einzelnen Refactoringschritte dauern immer nur ein paar Minuten und sind in der Gesamtschätzung enthalten.

Wenn man aber versucht, alten Spaghetticode durch Refactoring wieder in einen wartbaren Zustand zu bringen, sieht die Sache ganz anders aus. Dies ist ein kaum planbares Unterfangen mit hohem Zeit- und Aufwandsrisiko. Der Nutzen kommt dabei häufig erst, wenn die Arbeiten deutlich voran geschritten sind; oft wird also Monate lang ohne greifbaren Nutzen entwickelt, bis sich der “Knoten” plötzlich auflöst und ein deutlich besser wartbares Design entsteht, das exakt der alten Funktionalität entspricht - modulo der Fehler, die man üblicherweise während dieser Arbeit noch entdeckt und behebt.

Um die Situation etwas zu entschärfen, gehen wir bei solchen Vorhaben oft in mehreren Phasen vor, die sich bisher ganz gut bewährt haben (ich spreche hier von „wir“, weil ein solcher Umbau immer im Team oder mindestens von einem Paar durchgeführt werden muss, niemals von einem „Einzelkämpfer“):
Den Rest des Eintrags lesen »

Geschrieben in it-agile-blog-planet, Software Design, Refactoring, Agilität | 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 it-agile-blog-planet, Refactoring, Buchtipp, Agilität | Drucken | 4 Kommentare »