Für den Nissan Z-Club Schweiz durfte ich in meiner Freizeit eine neue Internetseite entwickeln.
Die Seite musste und beinhaltet nun folgende Punkte:
Das Resultat kann direkt unter www.z-club.ch angeschaut werden. Hier ein Vorgeschmack.. 
Ein Feature wird von den Erfindern von FDD wie folgt definiert:
The features are small “useful in the eyes of the client” results.
FDD ist eine kundenorientierte Entwicklungsmethode mit kleinen Teilresultaten. Die Grösse eines Feature wird weiter eingeschränkt durch die Bedingung, dass ein Feature in maximal zwei Wochen entwickelt werden sollte, andernfalls muss es weiter aufgeteilt werden bis diese Vorgabe erfüllt werden kann. Der Vorteil einer solchen Vorgabe wird in der Motivation der Programmier und in der Messbarkeit der Resultate gesehen. Durch die häufige Erreichung eines brauchbaren und sichtbaren Resultats, d.h. alle zwei Wochen, kann die Motivation der Programmierer Aufrecht erhalten werden. Der Abschluss eines Feature kann zudem von den Projektverantwortlichen und den Manager zum Feststellen des Projektfortschritts verwendet werden. Da ein Feature als kundenorientiertes Resultat definiert ist, ist die Fertigstellung eines Feature auch ein für Nichtinformatiker verständlicher Meilenstein: ein Manager oder der Kunde kann sich unter dem Resultat etwas vorstellen. Der Aufwand für kleine Teilresultate kann besser geschätzt werden und deshalb erlaubt FDD eine bessere Projektkontrolle.
Die Prozesse für das Feature-Driven Development werden bewusst kurz und simpel gehalten, weil die Autoren die Meinung vertreten, dass eine Überspezifikation mehr schadet als nützt. Einen bis ins kleinste Detail definierten Prozess kann die schlussendlich benötigte Entwicklung eines Programms nicht ersetzen. Nichtsdestotrotz wird auf Prozesse im FDD aus folgenden Gründen nicht verzichtet:
Beim ersten Punkt geht es darum, ein bestimmtes Verhalten bei den involvierten Personen zu schulen, welches auch in späteren und neuen Projekten zum Erfolg führt. Ein simpler und klar definierter Prozess soll zu einer guten Gewohnheit werden. Zweitens kann mit einem simplen und klar definierten Prozess die Einarbeitungszeit für neue Mitarbeiter verkürzt werden. Drittens sollte sich die Entwicklung auf die wichtigen Punkte konzentrieren und Prioritäten setzen. Die Anforderungen sollen gewichtet sein nach “must-have”, “nice-to-have” etc.
Für weitere Informationen verweise ich auf Wikipedia…
Der Hauptunterschied zwischen FDD Feature Driven Development und den anderen Agilen Methoden ist, dass bei diesem Vorgehensmodell als erster Projektschritt ein relativ detailiertes Modell des Gesamtprojektes erstellt wird. Von diesem Modell wird eine Liste von Features abgeleitet, aus denen das Gesamtmodell besteht. Im Gegensatz zu Extreme Programming, bei dem niemand auf ein Stück Code Besitz erheben kann, gibt es bei FDD zu jedem Feature einen Verantwortlichen, den sogenannten Feature Owner. Meiner Ansicht nach ist dieses Vorgehensmodell für grosse und komplexe Projekte ungeeignet.
In einem nächsten Schritt habe ich mir das APM Verfahren der Firma oose Innovative Informatik GmbH angeschaut.
Wie bereits im Teil 1 und Teil 2 erwähnt, gibt es verschiedene bekannte Verfahren, die alle Mitte/Ende der 1990er-Jahre erstmals publiziert wurden. In der Praxis des deutschen Sprachraums gehören Scrum und XP zu den beliebtesten Verfahren.
Das APM-Verfahren hat die grössten Ähnlichkeiten mit Scrum, vor allem bei den Techniken auf der Mikroebene. Scrum macht in diesem Bereich klare Vorgaben beispielsweise bezüglich der Rollen, Dauer von Sprints und spezieller Meetings.
APM beinhaltet Elemente aus Scrum, die aufgrund der eigenständigen Entwicklung teilweise jedoch unter anderem Namen oder in anderer Ausprägung existieren. Scrum beinhaltet eine eigene Terminologie (bspw. Product Backlog, Sprints, Sprint Backlog), während man sich beim APM-Verfahren eher an traditionelle Terminologien orientiert. (bspw. Arbeitsauftrag, Featureliste, Releaseplan). Das APM-Verfahren lehnt sich also bezüglich Methodik, Konzepten und Terminologie so weit wie möglich an klassichen Projektmanagementverfahren. Ausgangspunkt ist daher nicht die Unterstützung von Entwicklerteams durch Mikromanagementtechniken, sondern ein umfassendes Projektmanagement.
APM ist quasi eine Erweiterung und Ergänzung traditioneller Projektmanagementansätzen und auf diesen wird aufgebaut. Agilität heisst Beweglichkeit. Beweglichkeit setzt Freiräume und Freiheiten voraus, das heisst Abweichung von Standards oder vorgegebenen vielleicht starren, aber möglicherweise auch bewährten Regelwerken. Wo immer Freiheit entsteht, gibt es Verantwortung als Kehrseite der Medaille. Freiheit ohne Verantwortung ist egoistisch und einseitige Interessenverfolgung. Verantwortung wiederum setzt Kompetenz voraus.
Bezogen auf agiles Projektmanagement heisst dies, dass von agilen Projektteams und Führungskräften in agilen Projekten eine höhere Projektmanagementkompetenz erwartet wird, als von solchen aus herkömmlichen Projekten.
Das APM-Buch ist im Vergleich zum Buch von Roman Picher deutlich umfassender, kommt auf 440 Seiten und ist anders aufgebaut. Der eigentliche methodische Teil ist auch nur ca. 220 Seiten stark und macht den vorderen Teil des Buches aus. Anhand eines durchgängigen Fallbeispiels eines Grossprojekts werden in chronologischer Reihenfolge die Projektvorbereitung, die Projektplanung, die Release-Planung, Iterationsvorbereitung, Iterationsdurchführung, Iterationsnachbereitung und schliesslich Release- bzw. Projektabschlüsse behandelt. Der ganze hintere Teil des Buches ist eine werkzeugkastenähnliche Sammlung von fast einhundert Einzeltechniken, Mustern und Methoden, die nach den Wissensgebieten des PMI (Project Management Institute) gegliedert sind: Inhalts- und Umfangsmanagement, Zeitmanagement, Kostenmanagement, Qualitätsmanagement, Personalmanagement, Kommunikationsmanagement (hier geht es sehr stark auch um soziale Themen), Risikomanagement und Vertrags- und Einkaufsmanagement.
Die erstellte Präsentation soll kurz die Abläufe und Begrifflichkeiten von APM aufzeigen. Die Ähnlichkeiten zu Scrum sind frappant. –> Starte Präsentation
Wie so eben erläutert, beinhaltet der zweite grosse Teil des Buches einige Techniken, Muster, Modelle und Standards. Die Auswahl der in diesem “Werkzeugkasten” enthaltenen Elemente ist eine Untermenge des oose-Projektmanagement-Werkzeugkastens und bringt agile Teile in den Projektmanagementstandard des nicht prozessorientierten PMI.
Nachfolgend liste ich einige agile Teile aus dem Buch und referenziere diese mit den Kategorien aus PMI.
Ein Produktkartion dient als Metapher für ein zu erstellendes Produkt und beschreibt in wenigen Sätzen, die grundlegende Systemidee, die hinter dem Produkt steht. Zum einen hilft ein Produktkarton, sich auf das Wesentliche zu konzentrieren, da der Platz auf einem Karton begrenzt ist. Zum anderen hilft er, die Formulierung plastisch zu halten, da allen Beteiligten die zu verwendende Sprache aus realen Produktkartons bekannt ist.
ZAK-Karten sind eine strukturierte Beschreibungsform zur Setzung oder Vereinbarung von Zielen mit nach Möglichkeit objektivierbaren Erfolgskriterien bzw. Kennzahlen. In der einfachsten Form werden Ziele mit jeweils einer sogenannten ZAK-Karte beschrieben, die das Ziel, die notwendigen Aktionen oder Massnahmen dazu sowie eine Kennzahl zur Messung der Zielerreichung enthalten. (Ähnlich zu den Story-Cards in Scrum)
Diese Modell beschreibt einen Zusammenhang zwischen dem Erfüllungsgrad bestimmer Anforderungen und der Kundenzufriedenheit. Es eignet sich, um gezielt nach Innovationen zu suchen und ein Produkt so masszuschneidern, dass unter gegebenen Rahmenparametern maximale Kundenzufriedenheit erreicht werden kann. Es geht davon aus, dass sich Anforderungen, die Kunden an ein Produkt haben, in 3 Bereiche unterteilen lassen: Basis-, Leistungs- und Begeisterungsanforderungen.
Kunden reagieren auf der Grad der Erfüllung dieser Anforderungen unterschiedlich (siehe Grafik). Kunden entwickeln keinen hohen Grad an Zufriedenheit, wenn ein Produkt nur Basisanfoderungen abdeckt. Diese gelten als selbstverständlich und werden oftmals auch nicht explizit kommuniziert. Es ist daher wichtig, die latent vorhandenen Basisanfoderungen an das Produkt zu ermitteln, und es ist sinnlos, die Basisanforderungen überzuerfüllen, weil sie das subjektive Zufriedenheitsempfinden des Kunden nicht steigern.
Wie bei Scrum gibt es auch bei APM eine Burn-down-Chart. Es handelt sich um eine grafische Darstellung eines Fortschritts entlang der Zeit (x-Achse). Auf der y-Achse wird dabei übelicherweise die noch zu erledigende Arbeit aufgetragen, sodass die Kurve sich entlang der Zeit nach unten entwickelt.
Feedback zu geben und zu nehmen ist gar nicht so einfach. Wenn man nicht aufpasst, kommt es zu Missverständnissen, emotionalen Verletzungen, Vorwürfen, Demütigungen, Demotivation und Ähnlichem. Das Auto-Kritiker-Treffen bietet eine konstruktive Struktur, sachlich, mit Wertschätzung und frei von emotionalen Verletzungen Kritik zu erfahren und daraus zu lernen.
Es ist ein dreiteiliges Arbeitstreffen bei dem
Ein neutraler Moderator wird festgelegt, der das Treffen leiten wird.
Ergänzende Informationen sind in weiteren Beiträgen zu finden..
http://techtalk.fabio.li/wordpress/?p=281
http://techtalk.fabio.li/wordpress/?p=66
http://techtalk.fabio.li/wordpress/?p=22
Eine vollständig oder teilweise neu zusammenkommende Gruppe von Menschen, beispielsweise in einem Softwareentwicklungsprojekt, durchläuft typischerweise bestimmte Phasen. In jeder Phase sind andere Aspekte wichtig, und sie beeinflussen die Arbeitsfähigkeit der Gruppe. Die Kenntnis um solche gruppendynamische Phasen ist wichtig, da sie zu berücksichtigen sind. Die Phasen können nicht künstlich herbeigeführt werden.
Bei einem Problem, nur (einmal) nach dem “Warum” zu fragen, reicht nicht aus. Es soll mehrmals nacheinander die “Warum” frage gestellt werden, da die ersten Antworten nur Symptome und Phänomene zutage fördern, aber noch nicht die Ursache darstellen.
Eine ebenfalls spannende Art zur Diskussionsführung lautet Fishbowl. Hierbei diskutiert eine kleine Gruppe von Teilnehmern des Plenums im Innenkreis (im “Goldfisch-Glas”) exemplarisch die Thematik, während die übrigen Teilnehmer in einem Aussenkreis die Diskussion beobachten. Möchte ein Teilnehmer aus dem Aussenkreis zur Diskussion beitragen, kann er mit einem Mitglied des Innenkreises die Plätze tauschen. Die Arbeit des Innenkreises kann am Ende mit der gesamten Gruppe besprochen werden.
Der Hauptvorteil besteht darin, dass die Diskussionsrunde überschaubarer ist, da immer nur eine kleine Anzahl von Teilnehmern gleichzeitig diskutieren kann. Mitglieder, die sonst nicht zu Wort kommen, können in den Innenkreis wechseln und kommen dort schnell an die Reihe, ihre Meinung zu äussern. Des Weiteren kann ein Teilnehmer, der keine Lust mehr hat, einfach aussteigen und zuhören. Die Methode bietet sich ausserdem an, Dominanzverhältnisse aufzuzeigen: Aufdringliche Teilnehmer müssen sich beständig wieder in den Innenkreis begeben.
Ein kleines und häufig spontan organisiertes Treffen in lockerer Atmosphäre, um ein kleines, aber wichtiges Ereignis zu feiern. … mehr muss dazu nicht erwähnt werden
In mittleren und grossen Projekten kommen gewöhnlich viele Menschen zusammen, die sich bis dahin nur flüchtig oder gar nicht kannten, wodurch die Personen gegenseitig ihre Namen, Aufgaben etc. nicht kennen und gegebenenfalls sehr unsicher im Umgang miteinander sind. Jeder entscheidet selber, was und wie viel er von sich preisgeben möchte. Diese Angaben sind jedoch wichtig und hilfreich, weil die Menschen darüber einfacher in Kontakt treten können. Die Firma namics geht diesbezüglich einen Schritt weiter und publiziert diese Informationen sogar auf dem Internet (siehe Link).
Ich erachte das APM Verfahren als äusserst spannend. Die Ähnlichkeiten zu Scrum sind enorm, was auch die Autoren des Buches besagen.
„When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.“
Der Katalog mit den agilen Techniken, Modellen und Standards kann sicherlich bei Umsetzung eines agilen Entwicklungsprozess hilfreich sein.
Für den ersten Kontakt mit Scrum habe ich das Buch Scrum Agiles Projektmanagement erfolgreich einsetzen von Roman Pichler gelesen. Der Autor gibt einen gut angelegten, sehr strukturierten Einstieg in Scrum.
Scrum ist ein agiles Managementframework, das sich auf alle Arten der Softwareentwicklung anwenden lässt. Als agiles Framework verkörpert Scrum die Werte des Agilen Manifestes, welche wie folgt formuliert sind:
Das erfolgreiche Anwenden von Scrum ist ein Lernprozess, der Zeit und Geduld benötigt und neben den Teammitgliedern, dem Scrum Master und dem Product Owner auch das Management betrifft. In diesem Buch werden die folgenden Themen behandelt:
Michael Keller – ein ehemaliger Arbeitskollege -hat bereits eine hervorragende Zusammenfassung zu Scrum erstellt, welche ich noch ein wenig angepasst habe. –> Besten Dank !!!
Abschliessend möchte ich erwähnen, dass Softwareentwicklung schwierig und herausfordernd ist. An dieser Tatsache ändert auch Scrum nichts. Denn das Wesen der Softwareentwicklung ist Innovation und Kreativität.
Weitere Informationen findest du unter http://soup.fabio.li oder direkt bei http://delicious.com/enriico. Als nächstes beschreibe ich den APM Prozess.
Da komplexe Software in einer grösseren Umgebung anspruchsvoll zu erstellen und zu warten ist, bedienen sich Softwareentwickler eines Planes zur Entwicklung von Software. Ich setzte mich im Moment mit solchen Plänen oder auch Vorgehensmodellen auseinander und lese verschiedene Bücher und Fachartikel. Abgerundet wird das Ganze mit dem Besuch der Set Konferenz im Mai. Über einige der Erkenntnisse berichte ich hier in diesem Techtalk. Primär geht es mir darum verschiedene Entwicklungsprozesse kennenzulernen, Wissen aufzufrischen und die Besten Ansätze für meinen Arbeitgeber zu finden.
Eines haben alle diese Vorgehensmodelle gemeinsam und zwar unterteilen sie den Entwicklungsprozess in überschaubare, zeitlich und inhaltlich begrenzte Phasen oder Iterationen. Meines Erachtens unterscheiden sich solche Vorgehensmodelle vorwiegend im Detailierungsgrad oder wie in der heutigen Sprache üblich gesagt wird, zwischen agilen und nicht agilen Vorgehensmodellen.
Die Liste der verschiedenen Softwareentwicklungsprozesse ist umfassend und nicht abschliessend (siehe http://de.wikipedia.org/wiki/Liste_von_Softwareentwicklungsprozessen). Ich konzentriere mich auf die Folgenden:
Nicht agile Prozesse
Agile Prozesse
Zu den nicht agilen Prozessmodellen liste ich lediglich die Vor- und Nachteile auf, da mir diese bereits aus dem Studium und anderen Orten bekannt sind.
Als erstes beschäftige ich mich mit Scrum.
Fast einen ganzen Monat habe ich dazu benötigt, das Buch Adrenalin Junkies & Formular Zombies zu lesen und so folgt nun wieder einmal ein Eintrag meinerseits.
Nerd, Überflieger, Bandit, Leckermaul, Zicke, Primadonna, Wichser, Workaholic … Es gibt viele Begriffe, die menschliches Verhalten im Alltag anschaulich beschreiben. Für das Verhalten in Softwareentwicklungs-Projekten kennt man solche Begriffe nicht. In diesem Buch werden sie genannt. Die Mitglieder der Atlantic Systems Guild, die auch die Autoren von Büchern wie “Der Termin”, “Mastering the Requirements Process”, “Wien wartet auf Dich” und vieler mehr sind, haben Tausende von Projekten unter die Lupe genommen und beschreiben hier typische Verhaltensweisen, schädliche wie nützliche. Sie zeigen, wie man mit Schönreden, Management nach Gemütslage, Bleistiftstummeln oder Filmkritikern Projekte in Schwierigkeiten bringen kann. Dagegen lässt sich die Arbeit der Entwicklungsteams mit Nicht lange schnacken, Endspiel üben, Natürlicher Autorität und – nicht zu vergessen – Essen++ befördern.
Das Buch ist in 86 Kapitel gegliedert und wurde von 6 verschiedenen Autoren geschrieben. Auf Grund dessen wirken die Themen für mich etwas zusammengewürfelt. Die Themen werden kurz und bündig erläutert. Auf eine Zusammenfassung verzichte ich an dieser Stelle, da es für mich ein passendes Nachschlagewerk für zukünftige Arbeiten darstellt. Die Beispiele und Beschreibungen lassen sich ideal in eine Präsentation integrieren und geben der vermittelnden Thematik die nötige Gewichtung.
Diese Lektüre ist auch als Ebook erhältlich…
Ich möchte euch gleich vorab darauf aufmerksam machen, dass es sich in diesem Buch um kein Themengebiet der Informatik handelt, sondern das Leben von Albert Nufer erzählt.
Die Autorin Liana Ruckstuhl hat im Auftrag des Typotron-Heftes eine umfassende Biografie von diesem einzigartigen Original? Paradiesvogel? Pensionör verfasst. Wer in der Stadt St. Gallen schon unterwegs war, der hatte ihn sicherlich schon angetroffen. Er arbeitete fast 20 Jahre als Strassenwischer und für ihn war dies ein wunderbarer Beruf: “Ich sagte immer, es wäre wie mit dem Besen die Mutter Erde streicheln und das hörten die Leute immer gern. Ich hatte das Gefühl, priviligiert zu sein, wenn die anderen irgend in einem Büro oder vor dem Computer sitzen mussten.” Durch sein äusseres Erscheinungsbild und seinen Lebensstil wird er von vielen belacht, durch sein politisches Engagement als Stadt- und Kantonsparlamentarier aber dennoch geachtet. Obwohl er die Partei der Grünen gegründet hatte, vertrat er nicht immer die Interessen derer, sondern seine eigene Meinung.
Er lebt ohne festen Job und Wohnsitz in Armut. Nach eigener Aussage wählte er aus Überzeugung diesen Lebensstil und erledigte gegen Kost und Logis Arbeiten wie Schneeräumen, die Strasse wischen, Heuen oder Holzfällen, arbeitete in Weinhandlungen, Familienhaushalt oder auch einer Schreinerei. Seine Wohnung war eine isolierte Dachmansarde mit einem Holzofen. Er besitzt weder einen Fernseher, einen Computer noch ein Telefon.
Bereits als kleines Kind habe ich mich immer wieder gefragt, wer diese Person ist? Warum sieht dieser Mann so ungepflegt aus? Was hat ihn bewegt? Was hat er erlebt? Nach dieser einzigartigen Biografie konnte ich meine Fragen beantworten und habe einiges dazu gelernt. Für Albert Nufer war reisen etwas ganz besonderes in seinem Leben. Um seine Träume erfüllen zu können, brauchte er kein Geld und wenn er doch etwas brauchte, so ging er arbeiten. Viel mehr möchte ich nicht über ihn verlieren, sondern freue mich über spannende Dialoge mit Personen, die ihn kennen oder auch das Buch gelesen haben. –> Buch bestellen bei Typotron
Softwareprojekte richtig zu managen, ist eine Kunst für sich. Tom DeMarco zeigt im Buch “Der Termin” auf, wie ein Projekt trotz der zahlreichen Stolpersteine – die einem Projektmanager von der Konzeption bis zum Abschluss in den Weg gelegt werden – erfolgreich abgeschlossen werden kann.
Der Roman beschreibt aus der Ich-Perspektive die Erlebnisse des kürzlich entlassenen Systemmanagers Webster Tompkins. Dieser wird von einer attraktiven Geheimagentin zu Beginn der Handlung in das fiktive postkommunistische Land Morovien entführt. Dort macht man Tompkins ein Angebot: Er soll die Entwicklung von sechs Softwareprojekten parallel managen. Zudem schenkt man ihm ein Tagebuch, in dem er seine gewonnenen Erkenntnisse sammelt. Diese über 100 Ratschläge beruhen auf DeMarcos Erfahrung im Bereich des Projektmanagements und sind im Anhang dieser Zusammenfassung aufgelistet.
Tompkins wird verschleppt. Hinter der Entführung steht der EFN (der Edle Führer der Nation), ein ehemaliger Softwaremagnat, der sich nun eine neue Herausforderung sucht und dafür ein ganzes Land kauft, um dessen IT-Sektor an die Weltspitze zu befördern – und dafür braucht er Tompkins.
Die Aufgaben, die dem Protagonisten gestellt wird, klingen anfangs nicht wie plumpe Erpressung, sondern eher verlockend: Ein grosser Pool qualifizierter Mitarbeiter, unbegrenzte finanzielle Mittel sowie die völlige Freiheit bei der Zeitplanung. Zudem erhält er weitreichende Entscheidungsfreiheit. Von solchen Bedingungen träumt jeder Projektmanager. Tompkins teilt daraufhin seine Mannschaft in jeweils drei Teams pro Produkt auf. Durch unterschiedliche Teamgrössen und Entwicklungsmethoden möchte er die Gelegenheit nutzen und neue Erkenntnisse über Managementmethoden erhalten. Er selbst nennt es das “Projektmanagement-Labor”. Dass die traumhaften Bedingungen von kurzer Dauer sind, dürfte auch Nichtexperten nicht verwundern.
Auf seinem Weg zum Ende des Projekts muss Tompkins auch zahlreiche kleine und grosse Probleme lösen. Im Mittelpunkt stehen dabei vor allem Widrigkeiten und deren Lösungs-Methoden beim Managen von Menschen und Teams, Methoden für die optimale Projektplanung sowie Prozessoptimierung.
Im Buch werden keine Informationen zum Thema Konfigurationsmanagement oder Produktabnahme erwähnt. Zudem ist der Teil für den Projektabschluss im Vergleich zu den anderen Abschnitten kurz gehalten. Der Fokus liegt bewusst beim Personal- und Prozessmanagement. Persönlich empfehle ich dieses Buch jenen, die im Alltag mit Projekten oder allgemein mit dem Projektmanagement konfrontiert werden.
Nachfolgend sind sämtliche Erfahrungen von DeMarcos aufgelistet:
Vertrauen heisst auf Latein „credere“, das Ursprungswort unseres Kredits. Die Welt gibt Kredite nur an Besitzende – Muhammad Yunus mit seiner Bank für die Armen nur an Besitzlose. Die Welt vertraut in Gelddingen nur Menschen, die bereits Geld haben – der Friedensnobelpreisträger schenkt jenen Menschen volles Vertrauen, die nichts haben, und setzt damit bei ihnen eine erstaunliche Kreativität frei. Der Wirtschaftswissenschaftler aus Bangladesch machte das radikale Querdenken zugunsten der Schwächsten der Welt zum erfolgreichen Modell eines neuen Sozialunternehmertums. Dank seiner Pionierleistung wurden bislang weltweit mehr als 100 Millionen Mittellose, vor allem Frauen, zu Unternehmern. Yunus entschloss den Ärmsten den Zugang zu sozialer Absicherung, Strom und modernen Kommunikationsmitteln, kurz zu einem Leben der Hoffnung.
Yunus will verändern, viel verändern, daran lässt er keinen Zweifel. Und er will überzeugen. Er will klarmachen, dass Lösungen praktisch umsetzbar sind, die bisher undenkbar erscheinen. Dafür setzt er die Mittel scharfer intellektueller Logik ein, gepaart mit der Gestik partnerschaftlichen Lernens. Er setzt niemanden herab, sondern hört immer mit höchster Aufmerksamkeit zu, so als wollte er niemals irgendwo die Lernchance, die in jeder menschlichen Begegnung steckt, versäumen. Er ist nicht der Besserwisser. Aber er hört besser zu als die anderen. Und er pocht darauf, dass jeder Mensch dieselbe Achtsamkeit, dieselbe Qualität des Zuhörens verdient. Yunus ist der Überzeugung, dass ein Grossteil der heutigen Weltprobleme dadurch entstanden sind, dass wir eine Hierarchie des Zuhörens schufen, in der nur so geannte Experten wirklich zählen und sich Gehör verschaffen.
Wie kann man bis heute in den Vorlesungssälen ehrenwerter Universitäten und in den Berichten renommierter Finanzinstitutionen von „Trickle-down-Effekten“ sprechen, die angeblich den Ärmsten zugutekommen, wenn man die Reichen – zusätzlich zu ihren spektakulären Gewinnen – noch weiter mit der Verbesserung ihrer Rahmenbedingungen motiviert, während man gleichzeitig das Ausbeutungssystem der Zinspraxis schlicht ignoriert? Der Schock, der den Professor traf, war zweifach. Einmal musste er die Nutzlosigkeit der traditionellen Volkswirtschaftslehre für die Lebenssituation der Armen einsehen. Und dann folgte bei Yunus der Schock über die Ignoranz seiner Gelehrtenzunft gegenüber dieser hoffnungslosen Ausbeutungssituation, in der die Ärmsten gefangen waren. Dieser Schock wurde noch einmal gesteigert, als er durch eine simple Befragung der Betroffenen feststellte, wie wenig eigentlich erforderlich war, um diesen Mechanismus der Armut zu durchbrechen. Er beauftragte eine Studentin, herauszufinden, wie hoch der Kredit wäre, den die Dorfbewohner bräuchten, um sich aus den Fängen der Zwischenhändler und Geldverleiher zu befreien und sich die Rohstoffe für ihre Arbeit selbst zu kaufen. Die Studentin kam mit einer Namensliste von 42 Personen zurück, die in der Summe ganze 856 Taka bäruchten – den Gegenwert von 27 US-Dollar! So lächerlich gering war der Preis für den Ausweg aus dem Teufelskreis der Armut. Er entschloss sich, diese 27 Dollar mit der Massgabe zu verleihen, das die Kreditnehmer diese Darlehen zurückzahlen sollten, sobald sie dazu in der Lage waren.
Die erste grosse, ja vielleicht entscheidenede Erkenntnis für die Entwicklung des gesamten Grameen Konzeptes war: Arme Menschen verfügen zwar über keine dinglichen Sicherheiten, also keine Sicherheiten in Form von Gebäuden oder sonstigen Sachwerten, die sie zur Übereignung an die Bank anbieten können für den Fall, dass sie ihren Kredit nicht zurückzahlen können. Sie verfügen dafür aber über eine viel bessere Sicherheit: ihren schicksalserprobten Überlebenswillen. Für diese Menschen ist ein Kredit die vermutlich einzige Chance, die sie in ihrem Leben erhalten, um aus eigener Kraft einer ansonsten hoffnungslosen Situation zu entkommen.
Ein weiterer wichtiger Sicherheitsfaktor für die einzigartigen Rückzahlungsquoten der Grameen Bank erwies sich etwas Überraschendes: das Geschlecht. Die Erfahrungen zeigten, dass Männer bei sonst gleichen Rahmenbedingungen ihre Kredite zu 85 Prozent zurückzahlten. Die Frauen kamen auf nahezu 100 Prozent. Bei der Grameen Bank sind die Verhältnisse auf den Kopf gestellt: 94 Prozent der Kreditnehmer sind weiblichen Geschlechts. Und diese sind damit zum allergrösten Teil gleichzeitig auch die Inhaberinnen der Grameen Bank, denn diese gehört zu 94 Prozent den Ärmsten selbst (sechs Prozent müssen aus rechtlichen Gründen in Bangladesch beim Staat verbleiben).
In einem Interview wurde Yunus gefragt: ” Hatte Ihr Kleinkreditkonzept denn keine Feinde?” “Doch, alle”, antwortete Yunus mit einer selbstverständlichen, fast heiteren Ruhe, als wäre es das Normalste der Welt, dass man alle gegen sich hat, wenn man Neues und Innovatives umzusetzen versucht. Im Buch schilderte er dann, wie die Wucherer in Existenzängste verfielen, erzählte von ihren aggressiven Wutattacken, als es plötzlich viel billigere Kredite gab, er berichtete, wie die Männer um ihre Vormachtstellung bangten, als ihre Frauen sich plötzlich von Ängsten um die allgemeine Moral gepackt wurden, als die Frauen zunehmen mehr Selbstbewusstsein an den Tag legten, er machte klar, wie die Behöreden plötzlich allerlei Bedenken äusserten ob der vielen neuen Entwicklungen, die das Kleinkreditwesen anstiess, und wie sich schliesslich auch die Hilfswerke durch ein Konzept angegriffen fühlten, das soziale Probleme ausgerechnet durch Banking lösen wollte. Kurz gesagt: Alle waren dagegen.
Mit den Kleinkrediten befreit er die Ärmsten der Armen aus den Zwängen von Wucherern, fehlender Bildung und wirtschaftlicher Abhängigkeit. Dadurch schafft er eine langzeitige Entwicklungshilfe, aber nicht aus der Sicht einer Entwicklungsorganisation sondern aus der Sicht eines Sozialunternehmens. Mit der Grameen Bank hat er einen Weg gefunden, Millionen von armen Familien zu einer besseren Zukunft zu führen. Das Buch geht detailliert auf die Chancen und Problemen dieser Kleinkredite ein. Für mich ist das Buch etwas langatmig geschrieben, weshalb ich primär das Interview auf 3Sat empfehle.
Philosophie der Kreditgebung- Muhammad Yunus im Gespräch
Film
Von einem Kollegen habe ich das Buch „Agile Java-Entwicklung in der Praxis“ erhalten und bei einem Tempo von 100 S/h innerhalb von 4 Stunden gelesen *g*. Viele der darin enthaltenen Themen wurden bereits im Studium behandelt und begegnen einem stets im Alltag (oder sollten). Deshalb verweise ich auch gleich auf die beiden Zusammenfassungen SE1 und SE2, die von meinem Kommilitonen und mir verfasst wurden
Der Autor liefert eine kurze und kompakte Zusammenstellung agiler Techniken und Werkzeuge, doch der Zusammenhang fehlt. Im ersten Teil der agilen Softwareentwicklung hätte ich mir mehr Aspekte zum Faktor Teamarbeit gewünscht, anstatt beispielslose Techniken vorzustellen. Der zweite Teil über konkrete Werkzeuge wirkt zusammengewürfelt. Beispielsweise: JUnit und TestNG für Komponententests, Selenium und WebTest sowie Jemmy für funktionale und Akzeptanztests für Java Web- und Swing-Anwendungen, Subversion, Ant, Maven und CruiseControl für Konfigurationsmanagement und Build-Prozess, ergänzende Werkzeuge wie Checkstyle, EasyMock, Trac, usw…
Für Agile Ansätze empfehle ich z.B. die Seite von http://alistair.cockburn.us/ aufzurufen.
