10.9.2009 von Jens Coldewey.

Gemeinsam mit Traian Kaiser, Ralf Wirdemann und Stefan Roock habe wir auf XING ein neues Forum zum Thema “Lean Software Management” gestartet. Lesen ist frei, wer mitdiskutieren möchte, muss sich bei XING und in der Gruppe anmelden.

Zur Erinngerung: Lean Software Development ist eine “Unterdisziplin” der agilen Verfahren, die versucht, die Lehren und Erkenntnisse aus Lean Management und Lean Development von der Autoindustrie - und da vor allem von Toyota - auf die Entwicklung von Software zu übertragen. Basis sind vor allem die Arbeiten von Mary und Tom Poppendieck und ihre Bücher Lean Development Software: An Agile Toolkit for Software Development Managers und Implementing Lean Software Development: From Concept to Cash. Das Ergebnis ist erstaunlich ähnlich zu anderen agilen Verfahren wie Scrum etc., konzentriert sich aber deutlich mehr auf Zusammenhänge und weniger auf die genaue Einhaltung von Praktiken.

Eine Kurzfassung findet man in einem zweiteiligen Artikel von Mary Poppendieck und mir:

• Fastenkur für den Prozess in OBJEKTspektrum 4/2003
• Wir sind das Team in OBJEKTspektrum 4/2003

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

6.6.2009 von Jens Coldewey.

Meine Moderationsausbildung ist jetzt über 15 Jahre her und ich habe seitdem ein paar hundert Workshops, Meetings und Retrospektiven geplant und moderiert; von Routinemeetings bis hin zu emotional und politisch hochbrisanten Konfliktmeetings. Dass ich mir Sam Kaners Buch bestellt habe, lag eher daran, dass Diana Larsen ihn empfohlen hatte: Da musste ja was dran sein. Und es ist etwas dran, sogar sehr viel! Es ist tatsächlich das beste Buch zur Moderation, das ich bisher in der Hand hatte.

Kaner führt in einem sehr kurzen Theorieteil ein in die Gruppendynamik von gemeinsamen Entscheidungsprozessen, stellt dann alle möglichen Werkzeuge und Techniken für die Moderation vor, die jeweils mit Anwendungsbereich, Durchführung und Konsequenzen beschrieben werden, gibt Hinweise, wie man nachhaltige Übereinstimmung herstellt und stellt schließlich Techniken vor, um verbindliche Abschlüsse zu erreichen. Etwa 70-80% der Techniken waren mir bekannt, die anderen sind interessante Variationen, von denen ich sicher das eine oder andere in mein Portfolio aufnehmen werde. Anders formuliert, inhaltlich leistet das Buch das, was geleistet werden muss.

Begeistert hat mich aber die Präsentation: Jede Seite kann für sich stehen, man kann das Buch ebenso als Nachschlagewerk verwenden, wie zum Durchlesen. Jedes Kapitel gibt eine ein- bis zweiseitige Einführung in die Theorie des Themas, dann kommen Praktiken. So enthält alleine das Kapitel “Alternatives to Open Discussion” zwölf Varianten für Meetingformate:

• Small Groups
• Jigsaw
• Multi-Tasking
• Fishbowls
• Scrambler
• Roleplays
• Tradeshows
• Open Discussion
• Individual Writing
• Listing Ideas
• Presentations and Reports
• Structured Go-Arounds

Jedes einzelne Format wird mit Empfehlungen über den Einsatzbereich, genauen Anweisungen zur Durchführung und Variationen beschrieben, in der Regel inklusive der Auswirkungen auf die Gruppendynamik. Da gibt es sowohl für Neueinsteiger als auch für alte Hasen einiges zum Lesen und Nachschlagen. Er spart auch “heiße” Themen wie den Umgang mit “diverse communication behaviour” nicht aus.

Einziger Wermutstropfen, den ich bisher gefunden habe: Zu den Übungen sind praktisch keine Zeitangaben enthalten. Wenn man ein wenig Erfahrung hat, lässt sich das sicher verschmerzen, aber ich empfinde nach wie vor die Zeitangaben in Esther Derbys und Diana Larsens “Agile Retrospectives” als sehr hilfreich bei der Vorbereitung. Zur Ehrenrettung muss man allerdings auch erwähnen, dass Kaner natürlich viel breiter ansetzt und auf jede Form des Workshops anwendbar ist. Das macht Zeitangaben schwierig.

Kurz und gut: Eines der besten Bücher, die ich die letzten Jahre in die Finger bekommen habe und das sicherlich noch viele Stunden auf meinem Schreibtisch vor sich haben wird, auf einem Ehrenplatz neben dem Buch von Esther Derby und Diana Larsen.

Sam Kaner with Lenny Lind, Catherine Toldi, Sarah Fisk, and Duane Berger: “Facilitator’s Guide to Participatory Decision Making”, 2nd edition, Jonny-Bass/Wiley, 2007, ISBN 978-0-7879-8266-9, 341 Seiten

Geschrieben in Management, Buchtipp | Drucken | Keine Kommentare »

12.2.2009 von Jens Coldewey.

Ich wurde kürzlich von Peter Stevens auf der Deutschen Scrum Liste gefragt, wo man Crystal in zehn Minuten nachlesen könne. Ich denke, meine Antwort ist auch für Nicht-Scrummer interessant, deshalb hier noch mal in “voller Schönheit” mit ein paar zusätzlichen Links.

Gibt es irgendwo ein “Crystal in 10 Minuten”? - Ein google dafür hat nichts nützliches produziert…

Starte vielleicht mal mit http://alistair.cockburn.us/Crystal+light+methods, das dürfte ca. 10 Minuten dauern.

> Oder was ist besonders an Crystal?

Der Kern in drei Sätzen:

1. Arbeite in kurzen Iterationen
2. Mache regelmäßig Retrospektiven
3. Kommuniziere eng

Das ist sozusagen erstmal die Essenz agilen Arbeitens.

Basis sind Alistair Cockburns Überlegungen zur Software Entwicklung als kooperativem Spiel, sowie seine “Feldforschungen” seit den frühen Neunziger Jahren.

Um das zu unterstützen bietet Crystal sehr viele Praktiken, die sich je nach Kontext einsetzen lassen. Allerdings nicht wie Scrum oder XP (1.0) mit dem Hinweis “So muss man es machen”, sondern mit einem “in dieser Situation haben Teams gute Erfahrung gemacht, jenes zu machen mit folgenden Konsequenzen”. Meines Wissens lassen sich sowohl alle Scrum Praktiken als auch alle XP Praktiken mit Crystal abdecken.

Crystal ist damit viel näher an einer Patternsammlung, als an einem Prozess. Deshalb redet Alistair auch von einer “Methodenfamilie”, bei denen die Methoden nach Kritikalität und Teamgröße zusammen gesetzt werden mit dem Ziel, die “Gerade noch ausreichende Methode” zu finden. “Crystal Clear” ist zum Beispiel für Teams bis zu 10 Personen in Projekten, bei denen es nicht um Menschenleben geht. Er deklariert Crystal auch ganz klar als Hilfe für Fortgeschrittene und nicht als Anfängermethode (siehe dazu auch http://alistair.cockburn.us/Shu+Ha+Ri). Sein Ziel ist also nicht unbedingt Minimalismus in der Beschreibung, wie es von Scrum und XP verfolgt wird, sondern Minimalismus im Einsatz.

Crystal bildet damit die Brücke zwischen den agilen “Meta-Methoden” wie ASD (Jim Highsmith) und Lean Software Development (Mary und Tom Poppendieck) und den eher prozessartig gestalteten Verfahren wie XP und Scrum. Es ist ein Baukasten aus Praktiken mit Regeln, wie sie zusammen gesetzt werden.

Neben Alistair Cockburns Webseite gibt es zwei Bücher von ihm zu dem Thema:

• Agile Software Development: Das Buch enthält die Grundlagen agiler Verfahren und ein Kapitel über Crystal, sehr lesenswert
• Crystal Clear - A Human-Powered Methodology for Small Teams: Eine Beschreibung des “kleinsten” Mitgliedes der Crystal Familie mit einer Menge Praktiken

Das Zertifizierungsverfahren ist noch lange nicht so ausgefeilt, wie bei Scrum, es gibt aber immerhin eine handvoll “Certified Crystal Practitioners”, die zu der Ehre gekommen sind, weil Alistair ihre Arbeit gesehen und für gut befunden hat.

Geschrieben in Crystal, Buchtipp, Agilität | Drucken | 6 Kommentare »

22.1.2009 von Jens Coldewey.

Das von mir 2007 herausgegebene Heft des Cutter IT Journal mit dem Titel “Exploring the Agile Frontier” ist derzeit im Zuge einer Marketinginitiative von Cutter kostenlos erhältlich, statt des üblichen Preises von ca. $40.00. Das Heft sammelt Analysen und Projektberichte aus Bereichen, die üblicherweise als “wenig geeignet” für agile Verfahren gelten. Es enthält unter anderem:

• Einen Projektbericht über agiles Arbeiten in weltweit verteilten Teams bei Schlumberger von Lise Hvatum
• Einen Beitrag über agile Entwicklung bei großen und verteilten Teams von Jutta Eckstein
• Einen Projektbericht über die agile Entwicklung von Beatmungsgeräten von Klaus Marquardt der nach meinen Informationen nirgendwo anders veröffentlicht ist
• Einen Projektbericht über agiles Arbeiten bei einer “Wasserfall-Behörde” von Matt Ganis und Tom Hawkins

Sie finden das Heft, auf der Cutter Homepage unter “Sample Our Research” oder direkt hier.

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

1.12.2008 von Jens Coldewey.

Auf den XPDays in Hamburg stellte die Pychologin Maud Winkler das Tuckman-Modell der Teamentwicklung vor (genau genommen, das erweiterte Tuckman-Modell von Eberhard Stahl, das dieser in seinem Buch “Dynamik in Gruppen” vorstellt):

• Forming
• Storming
• Norming
• Performing
• Reforming

Die vierte Phase ist die produktivste Phase (wobei man hier vorsichtig sein muss, diese Phase nicht als konfliktfrei zu verstehen, nur werden hier Konflikte produktiv genutzt). Das Durchleben der anderen Phasen ist jedoch notwendige Voraussetzung dafür, dass das Team bei Performing gut arbeitet. Nicht erledigte Aufgaben aus den vorigen Phasen bleiben als Störfaktoren liegen und behindern das Team in der Arbeit. Um das Modell halbwegs realistisch zu gestalten, hat Eberhard Stahl das ursprüngliche Modell um eine iterative Komponente erweitert, die von Frau Winkler sehr betont wurde.

Dieses Modell erlaubt einen interessanten Blick auf agil geführte Teams. In diesen Teams werden regelmäßig Retrospektiven abgehalten, in denen sich das Team in eine Reflexionsphase begibt. Im Sinne des erweiterten Tuckman-Modells wird das Team also in regelmäßigen Abständen wieder in die Reformingphase “gestürzt”, die im Rahmen der Retrospektive bis zum Norming geführt wird. So werden sachliche und zwischenmenschliche Probleme auf einen klaren Zeitpunkt konzentriert, statt ständig im Untergrund zu rumoren.

Das bedeutet aber auch besondere Anforderungen an die Kompetenz des Moderators einer Retrospektive: Wer hier die Teamsituation falsch einschätzt oder angezeigte Interventionen unterlässt oder überspitzt, bewirkt bestenfalls, dass die “unproduktiven” Phasen während der Retrospektive nicht abgeschlossen werden und das Team weiter behindern. Schlimmstenfalls wird das Team gesprengt. Hier hilft ein erfahrener externer Moderator, der auch über den dafür notwendigen psychologischen Werkzeugkasten verfügt.

(Um einer Kritik an dem Modell zuvorzukommen, die Joseph Pelrine auf der Konferenz geäußert hat: Das Modell versucht weder einen Prozess zu beschreiben, noch erhebt es den Anspruch auf einzige Wahrheit. Es dient lediglich dazu, Anhaltspunkte für geeignete Intervention eines Leiters oder Moderators zu geben. Es ist also kein “RUP der Teamdynamik”, sondern eben “nur” ein psychologisches Modell, das ähnlich wie die einschlägigen Kommunikationsmodelle in bestimmten Situationen helfen kann, die aktuelle Situation zu verstehen. Zudem scheint mir das erweiterte Tuckman Modell wesentlich realistischer, als das recht lineare Original, auf das sich Joseph bezog).

Geschrieben in Management, Buchtipp, Konferenzen, 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 | 1 Kommentar »

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 »