In Softwareprojekte wird viel Geld investiert. Der Auftraggeber möchte, dass diese Investition Früchte trägt, zu neudeutsch: Er erwartet ein Return on Investment (ROI). Wie kann man mit Hilfe quantitativer Methoden diesen ROI tatsächlich erwirtschaften? Dieser Artikel führt zunächst grundsätzliche Messgrößen für Softwareprojekte ein. Danach wird gezeigt, wie man ein Softwareprojekt als wissensverarbeitendes System verstehen kann – dadurch wird das Managementwissen aus den Bereichen „Lean Production” und „Theory of Constraints” anwendbar. Schließlich erklärt der Artikel, wie dieses Wissen im Projektalltag angewendet wird.

Lesen Sie den Artikel auch online.

Johannes Link stellte auf Twitter eine sehr interessante Frage:

Warum zeigen so viele Agilisten ihr neues Tool Kanban mit einer wasserfall-artigen Arbeitsaufteilung?

(Im Dialog mit Johannes, den Sie auf Twitter nachlesen können, hatte ich Probleme, in 140 Zeichen darzustellen, was ich meine, deshalb hier dieser ausführliche Blog-Artikel.)

Der Grund für das, was die Kanban-Fans tun, ist wohl dieser: In Kanban gibt es fünf Schritte oder Kern-Eigenschaften der Methode:

1. Visualisiere den Workflow
2. Limitiere angefangene Arbeit (work in progress)
3. Messe und manage den Fluss
4. Mache Prozessrichtlinien explizit
5. Benutze Modelle (wie z.B. ToC), um Möglichkeiten zur Verbesserung zu erkennen

Der erste Schritt “Visualisiere den Workflow” tut genau das: Auf einem Taskboard stellt man dar, wie der aktuelle Workflow des/der Teams gerade ist. Nicht mehr und nicht weniger. Manche Teams beginnen mit Spalten wie “backlog, in progress, done” wie in XP oder Scrum und machen gute Erfahrungen damit. Andere Teams fügen weitere Spalten hinzu, wenn sie glauben, dass es nötig ist.

Beispiele für Workflow-Visualisierung

Ein Beispiel: In einem Scrum-Team, das ich aktuell coache, erkannten wir in einer Retrospektive, dass die Entwickler die Features oft sehr zeitnah entwickelten, die Karten auf dem Taskboard aber trotzdem sehr lange Zeit in der Spalte “in progress” verbrachten.

Der Grund war: Unsere Definition of Done schrieb vor, dass der Akzeptanztest durch den Product Owner Bestandteil des Begriffes “done” sein musste. Der Product Owner war jedoch in weiteren Projekten involviert und hatte fast nie sofort Zeit zu testen, sobald ein Feature fertig geworden war. Es bildete sich beim P.O. ein “Test-Stau” mit unangenehmem Ergebnis: Es gab öfters einmal ungetestete Karten, die dann eben nicht zum Sprint-Ergebnis gezählt werden konnten und sollten.

Dies wollten die Entwickler sichtbar machen und fügten dem Taskboard eine Spalte “acceptance test” hinzu. Nun konnte man erkennen, wie sich dort die Karten stapelten bis der Product Owner sie gegen Ende des Sprints abräumte – eine risikoreiche Vorgehensweise.

Ein anderes Scrum-Team, das ich kenne, verwendet eine separate Spalte mit der Überschrift “GUI design”. Dort werden Karten aufgehängt, die fast fertig entwickelt und auch schon inspizierbar sind, jedoch noch ohne eine richtig schöne und ergonomische Oberfläche, die danach erst durch eine externe UI-Designagentur geschaffen wird. Erst wenn die UIs von dort zurückkommen, wird die Karte auf “acceptance test”, danach auf “done” geschoben.

Vom Workflow zum Wasserfall

Zurück zur Frage von Johannes: Warum zeigen die Kanban-Leute wasserfall-artige Taskboards? Antwort: Sie tun es nicht – sie zeigen lediglich Workflows. Was ist der Unterschied? Ein Workflow ist einfach eine Reihe von Arbeitsschritten, die hintereinander ausgeführt werden. Um daraus einen Wasserfall zu machen, muss man mindestens noch folgende negative Eigenschaften hinzufügen:

1. Das “100% Losgröße”-Syndrom: Man führe jeden Workflow-Schritt mit 100% aller Anforderungen durch und gehe erst danach zum nächsten Schritt des Workflows. Auf keinen Fall das, was schon getan ist, schon mal in den nächsten Workflow-Schritt weiterreichen – das könnte ja unvollständig aussehen!
2. Das Isolations-Syndrom: Man lasse die Leute, die in einem Workflow-Schritt arbeiten, auf keinen Fall mit den Leuten aus einem anderen Workflow-Schritt zusammenarbeiten. Also darf ein Analyst niemals mit einem Architekten und dieser auch niemals mit einem Entwickler reden – alle dürfen nur über Dokumente miteinander kommunizieren, die durch ausführliche Reviews abgesichert und dann unterschrieben sind.

Kanban geht gegen den Wasserfall vor

In Kanban ist beides nicht der Fall. Mit der Kanban-Methode versucht  man im Gegenteil die Durchlaufzeit eines Features durch den Workflow zu minimieren. Wer Littles Gesetz kennt, weiß, dass das mit 100% aller Anforderungen nicht geht, sondern je weniger “work in progress” (angefangene Arbeit) man hat, desto kürzer ist die Durchlaufzeit. Deshalb limitiert man in Kanban die Zahl der gleichzeitig in Arbeit befindlichen Features.

Jeder, der arbeitet, soll die Gelegenheit haben, sich zu konzentrieren – also limitiert man die Zahl der Features z.B. auf 4, wenn man 3 Entwickler hat. Die drei Entwickler sollten im wesentlichen immer an je einem  Feature arbeiten, es sei denn, dieses ist blockiert, weil man auf eine Antwort wartet oder weil eine Ressource fehlt, die man braucht. Dann darf man sich ausnahmsweise ein 4. Feature ziehen.

Je geringer die Menge gleichzeitig angefangener Arbeit, desto geringer ist auch die Zahl der Fehler, die man einbaut. Menschen arbeiten wesentlich korrekter, wenn sie konzentriert sind. Dies reduziert die Zahl der Überarbeitungen, die notwendig sind, um ein Vielfaches!

Auch die Isolation, die im Wasserfall typisch ist, gibt es in Kanban nicht. Da Kanban aus dem agilen Umfeld stammt, ist Kommunikation ein hohes Gut. Man sollte immer mit den Leuten reden, die am selben Feature gearbeitet haben oder arbeiten werden wie man selbst. Der Entwickler wird den Business Analysten oder den Architekten fragen, der Tester wird den Entwickler fragen, was hinter gewissen Zusammenhängen eigentlich steckt. Viel besser ist es natürlich, wenn Business Analyst und Entwickler zum selben cross-funktionalen Team (wie in Scrum) gehören und das Feature gemeinsam analysieren und realisieren.

Die Kraft des Vakuums

Oben habe ich das Beispiel mit dem überlasteten Product Owner erwähnt, bei dem sich ein Test-Stau bildete. In Scrum würde man dies jetzt auf die Impediment-Liste des Scrum-Masters schreiben und dieser würde gegen den Effekt zu kämpfen beginnen. In Kanban würde man das vermutlich folgendermaßen lösen: Man würde für die Spalte “acceptance test” ein WIP-Limit einführen und z.B. auf die Menge einschränken, die der Product Owner in einem Time-Slot, den er sich bei seinen vielen Projekten nimmt, bewältigen kann. Hat er ab und zu mal zwei Stunden Zeit und kann darin 3 Features sauber testen, so würde man das “work in progress”(WIP)-Limit auf 3 setzen. Was würde dann passieren?

Schließen Sie die Augen und überlegen Sie eine Minute, bevor Sie weiterlesen!

Die Entwickler würden jedesmal, wenn sie etwas fertig haben, eine Karte in die Spalte “acceptance test” schieben. Kommt der Product Owner nicht zum Testen und enthält die Spalte nun 3 Karten, würden die Entwickler einfach aufhören zu entwickeln. Sie würden stattdessen vielleicht refaktorisieren, Urlaub machen, Schulungen besuchen, Kaffee trinken oder andere sinnvolle Tätigkeiten durchführen. Beim morgendlichen Stand-Up würden sie diese Tatsache auch sofort bekanntgeben.

Das Risiko, den Sprint mit einer ungetesteten Featuremenge zu beenden, würde dadurch drastisch abnehmen. Das Team inklusive P.O. wäre plötzlich als Gesamtsystem erkennbar, das einfach nicht in der Lage ist, mehr zu leisten als der P.O. fertigbekommt. Der P.O. wäre ganz klar als Bottleneck erkennbar.

Was würde als nächstes passieren, wenn niemand interveniert? Denken Sie einen Moment nach…

Das Vakuum greift um sich

Wenn die Entwickler weniger tun, staut sich plötzlich alles im Backlog zurück. Nehmen Sie an, wir hätten mittels Kanban auch die Länge des Backlogs limitiert. Die Leute, die bisher dem Product Owner geholfen haben, Features zu beschreiben und ins Backlog zu bringen (nennen wir sie “fachliche Analysten”), wären dann plötzlich ebenfalls arbeitslos, weil sie nichts mehr in das bereits volle (weil limitierte) Backlog stellen dürfen.

Oh, hier haben wir Analysten, also fachlich geschulte Leute, die frei sind! Was tun wir mit denen? Wir machen sie zu Testern, die zunächst einmal den Stau von Akzeptanztests abbauen und dadurch den P.O. entlasten. Damit wird die Spalte “acceptance test” wieder frei, die Entwickler nehmen die Arbeit wieder auf und produzieren wieder. Im Backlog werden dadurch wieder Plätze frei, also können die Analysten ihre eigentliche Arbeit wieder aufnehmen und neue Backlog-Items produzieren. Der Propfen löst sich.

Von der Taktik zur Strategie

Das gerade geschilderte Verhalten ist sicherlich nicht optimal, doch hat es erst einmal geholfen. Das Management wird inzwischen von der Aktion gehört haben und sich entscheiden, mehr Tester einzustellen, die dem Product Owner helfen. Die Tester kommen langsam auf Touren und der Propfen wird sich dann nicht mehr bilden müssen.

Die Antwort auf die Frage nach dem Wasserfall

Johannes Frage von oben könnte man nun anders formulieren:

Warum zeigen so viele Agilisten ihr neues Tool Kanban mit einer so ausführlichen Arbeitsaufteilung (so viele Spalten auf dem Taskboard)?

Weil sie zeigen wollen, was wirklich passiert. Das dreispaltige Scrum-Taskboard zeigt eben nicht, dass in der Sprint-Mitte typischerweise viel WIP entsteht, besonders bei unreifen Scrum-Teams, die noch nicht lange dabei sind. Führt man mehr Spalten ein, bildet man die Realität im Team u.U. besser ab und kann auf Effekte aufmerksam machen, die man vorher übersehen hat.

D’accord, Johannes?

Ich hatte mich entschieden, auf meinem Acer Aspire One Netbook eine neue Linux-Version (Ubuntu 10.04) zu installieren. Klappte auch wunderbar. Ubuntu heruntergeladen und auf einen USB-Stick geschrieben, mit dem Stick den Rechner gebootet und Ubuntu ganz einfach parallel zu Windows auf der Festplatte installiert. Rechner neu gebootet, und ich konnte mit Ubuntu oder Windows arbeiten, je nachdem, wie ich Lust hatte.

Doch leider: Beim einem der nächsten Restarts der Maschine kam es zu einem Black Screen Of Death, einem in der Acer-Community offenbar wohlbekannten Problem mit einem nicht mehr startbaren BIOS: Schwarzer Bildschirm nach dem Einschalten, keine Bootmeldungen, voller Stopp!

Gott sei Dank war das Problem relativ leicht zu beheben:

• Neues BIOS von der Acer-Supportseite laden.
• Auf einen frisch formatierten USB-Stick schreiben.
• Diesen magischen Anweisungen folgen und derweil beschwörende Sprüche murmeln.

Der Aspire One war danach wieder einsatzbereit. Manchmal hat man doch wirklich Glück, obwohl man es herausfordert.

Die Softwarearchitektur ist ein wichtiges Artefakt der Softwareentwicklung. Softwarearchitekten müssen kommunikationsstark sein, für die Durchsetzung der Architektur in den Projekten sorgen usw. Das ist die öffentliche Meinung. In der Projektrealität sieht es meist anders aus: Architekturdokumente werden mühsam erstellt, doch im Alltag nicht gelesen. Architekten versuchen, durch Predigen die Einhaltung der Architektur zu erreichen. Teams entwickeln, auch ohne auf die Architektur zu achten. Was wäre, wenn man Architektur emergieren lassen würde, quasi als “Ergebnis des Schwarms”, anstatt sie mit viel Kraft in Einzelleistung zu erstellen? Die folgende Geschichte ist ein Kondensat meiner Erfahrung aus vielen Projekten. Lesen Sie, warum Architektur letztlich nicht von Einzelnen gemacht werden kann, und erfahren Sie, was nötig ist, damit Emergenz möglich wird.

Wir, die Unterzeichner, haben keine Lust mehr, zu hören, wie viel von unserem Geld für fehlgeschlagene IT-Projekte der Regierung verpulvert wird.

Wir glauben, dass dies im Wesentlichen an der Art und Weise liegt, mit der diese Projekte ausgeschrieben und geliefert werden – nämlich, alle Anforderungen eines enormen Projektes im Vorhinein zu verlangen und sich darauf zu verpflichten. Das verurteilt Projekte dazu, fehlzuschlagen noch ehe sie begonnen haben.

Im privaten Sektor hat man sich bereits weitgehend von diesem falschen Modell zu einem inkrementellen Ansatz bewegt, der Änderungen im Verständnis und den Anforderungen erlaubt und die Wahrscheinlichkeit für einen Misserfolg enorm reduziert. Es ist an der Zeit, dass unsere Regierung das auch tut.

Wir bitten den Premierminister, den aktuellen Ansatz auf den Prüfstand zu stellen und für IT-Projekte der Regierung einen mehr inkrementellen und agilen Ansatz in Betracht zu ziehen.

Wow, das sollte hier in Deutschland auch gelten! Wo kann man hier eine ebensolche Petition abgeben? Ich wäre sofort dabei!

Umfragen unter Benutzern von IT-Systemen ergeben: Nur zwanzig Prozent der Funktionen eines IT-Systems werden “immer” oder “oft” benutzt, fast zwei Drittel hingegen “selten” oder “nie”. Diese Zahlen haben den Umgang mit Anforderungen in IT-Projekten verändert: Lernen im Projekt ist ausdrücklich erlaubt, Änderungen sind willkommen. Diese Situation stellt neue “Anforderungen an die Anforderungen”. Der Artikel zeigt, wie Anforderungen heute aussehen können, damit man mit ihnen sehr schlanke Projektverträge gestalten kann. “Money for nothing, changes for free” sind hier die zunächst unglaublich klingenden Stichworte. Auftrag geber und Entwicklungsorganisation ziehen am selben Strang, Änderungsanforderungen kosten ab jetzt kein zusätzliches Geld mehr und brauchen deshalb nicht mehr verhandelt zu werden.

Der rund eine Minute lange Film zeigt anschaulich, wodurch der Unterschied für den Kunden zu Stande kommt. Mehr über Flow gibt es hier.

Ist das in der Software-Entwicklung genauso? Die OOP hat sich ja in diesem Jahr auch so ein Motto auf die Fahne geschrieben: people, process, technology. Prüfen wir doch mal: people = mano e mente, process = macinatura, technology = macchina – nanu, wo bleibt miscela, die Mischung, der Rohstoff, aus dem die Software entstehen kann?

Alistair Cockburn hat diese Frage 2006 in einem Artikel beantwortet: “Software engineering … is remarkably like manufacturing, once we shift to view the unvalidated decision as the unit of internal inventory.” Die Mischung besteht also aus den bisher unvalidierten Entscheidungen, die in der Mühle und der Maschine immer weiter verarbeitet werden, bis der Benutzer seine neue Software in Händen hält.

Beispiele für solche unvalidierten Entscheidungen sind:

• Jede Anforderung ist eine Entscheidung, die auf einem bestimmten Geschäftsklima basiert. Wenn sich das Klima ändert, könnte die Entscheidung falsch werden.
• Eine Architektur ist eine Entscheidung, die auf Technologie und Business basiert. Wenn sich die Technologie verändert bevor die Software genügend Wert für das Business eingespielt hat, ist die Entscheidung verschwendet.
• Jede Zeile Code ist eine Entscheidung, basierend auf Anforderungen, Technologie und Ästhetik. Sollte eines davon obsolet werden bevor die Software genügend Geld für die Firma verdient hat, dann war auch das Verschwendung.

Halten wir also am besten die Zyklen kurz und schlank und erzeugen nur so wenig unvalidierte Entscheidungen wie möglich. Über Anforderungen rasch entscheiden, Entwurf und Programmierung zeitnah durchführen, dem Benutzer lauffähige Systeme in die Hand geben, die er sofort validieren kann. So bleibt der Kaffee frisch, weil die Bohnen nicht lange liegen.

Ich lade Sie ein, mit mir auf der OOP einen Kaffee zu trinken!

Ausgangssituation: Priorität gemeinsam festlegen

Sich zu einigen ist nicht ganz einfach. Man muss dabei folgende Fragen gleichzeitig beantworten:

• Wie viel geschäftlichen Vorteil bringt mir ein bestimmtes Feature?
• Bin ich bereit, den geschätzten Entwicklungsaufwand zu genehmigen?
• Was meinen die anderen Stakeholder dazu?
• Kriegen wir einen Konsens hin, so dass wir besser zwei ganze anstelle von vier halben Features beauftragen können?

Gestern war ich beim ersten Treffen dieses Gremiums, eingeladen als Coach für agile Methoden und Produktivität. Um möglichst einfach auf einen Konsens über die Prioritäten zu kommen, spielten wir das Innovationsspiel Buy a feature. (Danke an Michael Mahlberg, der die Idee hatte, dieses Spiel zu nehmen!)

Der Product Owner stellte die Stories (Features) aus dem Product Backlog mit Hilfe von User Story Karten vor. Die Entwickler hatten den Aufwand für diese Stories vorher in Story Points abgeschätzt, der Product Owner hatte den Aufwand auf den Karten vermerkt.

Spielregeln

Die Spielregeln für “Buy a feature” sind sehr einfach und wirkungsvoll:

• Jeder Stakeholder bekommt eine bestimmte Anzahl Münzen.
• Jedes Feature hat einen “Preis”, der durch den Entwicklungsaufwand bestimmt wird.
• Stakeholder “kaufen” nun die Features, die sie für wichtig halten, indem sie die Münzen auf die Story-Karten legen. Da sie nicht alles kaufen können, müssen sie priorisieren.
• Wenn eine Karte so viele Münzen bekommen hat wie ihr Preis angibt, gilt sie als gekauft und kommt ans obere Ende des Product Backlogs.

Als Münzen eignen sich farbige Plättchen, wie sie im Flohspiel verwendet werden. Die gibt es im Spielzeuggeschäft auch einzeln zu kaufen, ca. 5 Cent pro Stück. Eine separate Farbe pro Geschäftsbereich ist günstig, dann können Spieler ihre Münzen auch wiederfinden und auf andere Features legen, um z.B. einen Konsens zu bekommen.

Die Randbedingungen hatte ich wie folgt gesetzt:

• Ich gab nur so viele Münzen aus wie Story-Points in den ersten Sprint passen, orientiert an der Velocity des Teams.
• Der Product Owner stellte ungefähr doppelt so viele Features vor wie in den Sprint passen, damit die Stakeholder genügend Auswahl hatten.
• Die Stakeholder aus einem Geschäftsbereich bekamen mehr Münzen als die anderen, weil der erste “Launch” des neuen Systems im Wesentlichen die Belange dieses Geschäftsbereiches abdecken wird.

Der Ablauf des Spiels

Der Product Owner stellte die Features vor, jeweils als kurze Zusammenfassung der darin enthaltenen Funktionalität. Die Stakeholder stellten Fragen nach dem Inhalt, den Abhängigkeiten und der Abgrenzung der Features.

Danach bildeten die Geschäftsbereiche kleine Gruppen und diskutierten, welche Features für ihren Bereich Priorität bekommen sollten. Es bildete sich schnell eine diskutierende Traube von Leuten um die Karten, die auf dem Tisch lagen.

Nach ca. 10-15 Minuten begann der Sprecher des einen Geschäftsbereichs, seine Münzen auf die Features zu platzieren und argumentierte, warum er sich so entschieden hatte. Die anderen schlossen sich an und platzierten ebenfalls ihre Münzen. Da der Preis für manche Features zu hoch war, um durch einen einzelnen Bereich bezahlt zu werden, bildeten sich Allianzen um die Features, die als teuer und trotzdem wichtig erachtet wurden.

Eines der Features war besonders teuer, es handelte sich um die Entwicklung eines Grundkonzeptes, das für fast alle weiteren Sprints wichtig sein würde. Der Product Owner warb dafür, es trotz des hohen Preises zu kaufen. Einige Stakeholder argumentierten dagegen, mit der Begründung, je länger sie die lauffähigen Features testen könnten, die im ersten Sprint entstehen, umso besser. Ein Geschäftsbereich, dessen Launch-Datum noch weit in der Zukunft lag, sagte dann: “Für uns wäre dieses Feature extrem wichtig, doch ob das Konzept nun jetzt oder erst im nächsten Sprint kommt, ist uns egal. Wir stellen unser Geld deshalb den anderen zur Verfügung.” Wer hätte das für möglich gehalten?

Zum Schluss blieben einige nur teilweise finanzierte Features übrig. Die Gruppe verteilte deren Münzen so, dass ganze Features gekauft werden konnten. Alle Münzen waren ausgegeben, zehn Features für den ersten Sprint standen damit fest.

Ich fragte noch nach der Priorität dieser Features untereinander, da das Spiel ja nur eine reine Ja/Nein-Aussage liefert. Diese Reihenfolge ergab sich sehr schnell aus den Feature-Abhängigkeiten und aus der Frage: “Wenn die Entwickler in Stress kommen sollten, welches Feature darf dann am ehesten aus dem Sprint fallen?”. Wir sortierten die Karten nach dieser Reihenfolge, das Ergebnis sah aus wie auf dem Foto links.

Feedback vor und nach dem Spiel

Für die Gruppe der Stakeholder war es neu, Entscheidungen in wichtigen Dingen mittels spielerischer Verfahren zu finden. Zwei meldeten vor Beginn des Spiels Bedenken an: “Sonst haben wir solche Entscheidungen immer durch Diskussion gefunden. Ich glaube nicht, dass wir so ein Spiel brauchen.” Der Product Owner schlug vor, es erst einmal zu versuchen und falls es sich nicht bewährt, es wieder bleiben zu lassen. Ich erklärte, dass Diskussionen explizit erwünscht seien und niemand sofort kaufen müsse.

Nach dem Spiel fragte ich die Beteiligten nach ihrem Feedback. Es war einhellig positiv:

• “Die Visualisierung der Entscheidungen ist sehr gut.”
• “Man kommt sehr schnell zu einer Einigung.”
• “Es lockert diese Meetings auf und macht Spaß.”

Tja, da bleibt mir nur ein “Danke” an die Erfinder dieses Spiels. Ich kann es wirklich empfehlen!

Einer der Teilnehmer am Workshop in diesem Raum sagte: “Vielleicht ist das Gebäude agil entwickelt worden, die Anforderung für den 8. Stock kam erst später. Oder vielleicht wurden die Tests eingespart?”

Allgemeines Gelächter in der Gruppe.

Das bringt mich auf die Frage: Wann ist es eigentlich sinnvoll, agil zu entwickeln und bei unvollständigen Informationen trotzdem weiterzumachen? Eigentlich ganz einfach: Agil zu entwickeln ist angebracht, wenn die Kosten für nachträgliche Änderungen geringer sind als die Verschwendung (waste, muda), die durch das Streben nach initialer Perfektion der Anforderungen ausgelöst werden würde.

Wann gilt diese Bedingung? Wahrscheinlich für fast alle “normalen” Softwareprojekte – für nur ganz wenige gilt sie nicht. In diesen Fällen sollte man dann besser nicht agil entwickeln.

Was meinen Sie – wann sollte man besser zuerst perfekt planen, dann umsetzen?

Lesenswert!

These 1: Menschen leisten am meisten, wenn sie motiviert sind. Zumindest, wenn das Rennen über eine längere Strecke gehen wird. Kurze Strecken hoher Leistung sind auch rein aus Anstrengung machbar, bei längeren Strecken kommt die Energie am besten aus der Begeisterung. Softwareentwicklung gehört zu den längeren Rennen.

These 2: Softwareentwicklung ist ein Spezialfall von Arbeit mit Wissen, und zwar mit einem Wissen, das nicht von Anfang an komplett vorhanden ist, sondern eines, das wie ein stetiger Strom während der gesamten Projektlaufzeit ins Team fließt.

These 3: Wissensarbeit ist wie ein kooperatives Spiel – es gibt dabei keinen, der vernünftigerweise allein bestimmen könnte, was als Nächstes der beste Spielzug ist. Das gilt insbesondere sogar für den Projektleiter – er muss die Entscheidung über den besten nächsten Zug seinen Mitarbeitern überlassen.

Formen der Führung

Je nach der Komplexität der Arbeit, die die Teams leisten, muss der Führungsstil angepasst werden, damit die Sache ein Erfolg wird. Sehr einfache Arbeit kann man mittels Kommando und Kontrolle managen. Für etwas komplexere Aufgaben sind Zielvorgaben und Belohnung bei Zielerreichung das Richtige. Noch komplexere managt man durch charismatische Führung. Für höchst komplexe Tätigkeiten wie die Softwareentwicklung erreicht man die besten Ergebnisse, wenn man Selbstorganisation zum Prinzip macht. Niemand anderes als das Team weiß am besten, was in der aktuellen Situation zu tun ist. Als Manager nutzt man dieses Wissen und stellt dem Team lediglich eine Dienstleistung namens Führung zur Verfügung.

Robert K. Greenleaf hat vor einigen Jahrzehnten schon Essays dazu verfasst, das gemeinsame Thema hieß Servant Leadership, im Prinzip “Führung als Dienstleistung”. James A. Autry hat Greenleafs Erkenntnisse weiter konkretisiert, in seinem Buch von 2001: The Servant Leader: How to Build a Creative Team, Develop Great Morale, and Improve Bottom-Line Performance. Darin finden sich einige interessante Kernaussagen:

1. Bei Führung geht es nicht um das Steuern von Leuten; es geht darum, für Leute zu sorgen und eine nützliche Ressource für die Leute zu sein.
2. Führung bedeutet nicht, der Boss zu sein; es geht darum, für Leute präsent zu sein und eine Gemeinschaft am Arbeitsplatz aufzubauen.
3. Bei Führung geht es nicht um die Verteidigung von Territorium; es geht darum, Ihr Ego loszulassen, Ihren Geist mit zur Arbeit zu bringen und Ihr bestes und möglichst authentisches Selbst zu sein.
4. Führung befasst sich nicht so sehr damit, Anfeuerungsreden zu halten, sondern damit, wie man einen Platz schafft, an dem Leute gute Arbeit machen können, darin einen Sinn finden und ihren Geist zur Arbeit mitbringen.
5. Führung ist, wie das Leben, größtenteils eine Frage der Aufmerksamkeit.
6. Führung erfordert Liebe.

Motivation und Produktivität

Wenn ich die obigen Kernaussagen von Autry lese, denke ich “Wow, so möchte ich als Teammitglied geführt werden!” Ein Manager ist in der Lage, eine Umgebung für Motivation und gute Arbeit zu schaffen, wenn er diese Sätze tief verinnerlicht und danach handelt. Nebenbei: Dann wird ihm sein Job auch richtig Spaß machen, weil er mit dem, was sein Team braucht, in Resonanz kommt.

Produktivität stellt sich dann durch Selbstorganisation des Teams ein, bei der der Manager lediglich Unterstützung leistet. Soziale Systeme entwickeln Verhalten, sie organisieren sich selbt aufgrund von Regeln, Feedback und Diskurs. Es beginnt mit einfachen Regeln, z.B. “Wir wollen nur Code einchecken, der den Build übersteht und fehlerfrei durch alle Unit-Tests geht.” Wenn jemand eine solche, gemeinsam anerkannte Regel verletzt, indem er schlechten Code eincheckt, bekommt er von den Teamkollegen (und vom CI-Server) Feedback. Er wird sich vermutlich wundern, mit seinen Kollegen ins Gespräch kommen. Zuletzt wird er die Ursache herausfinden und beheben, indem er vor dem Einchecken zunächst seine Arbeitsumgebung aktualisiert, alle Unit-Tests laufenlässt und Fehler lokal behebt, bevor er nochmals eincheckt. Das ist eine Verhaltensveränderung, Selbstorganisation durch Feedback und Diskurs. Die Produktivität des Teams wird ansteigen, weil wieder einer weniger “im Weg steht”.

Der Manager als Mentor

Als Manager oder Coach kann ich diesen Prozess der Selbstorganisation fördern, indem ich genug Quellen für Feedback schaffe, Menschen ermutige, Feedback zu geben und in den Diskurs zu gehen. Ich kann das Team fragen, welche anerkannten Regeln für das gemeinsame Handeln gelten müssen und die Verabschiedung dieser Regeln fördern. Ich kann Regeln auch hinterfragen (lassen), wenn mehrfach gegen sie verstoßen wird oder wenn das Team so reif wird, dass sie weniger Regeln brauchen.

Das alles ist, wie das Leben, größtenteils eine Frage der Aufmerksamkeit.

In allen agilen Methoden versucht das Entwicklungsteam, dem Kunden ein gewünschtes Feature möglichst schnell zur Verfügung zu stellen. Das ist ein wichtiger Bestandteil des Entwicklungsprozesses: zeitnahe Lieferung löst zeitnahes Feedback aus und hilft, das Projekt auf der Spur zu halten.

Die agilen Methoden können dabei von den jahrzehntelangen Erfahrungen aus der Lean Production profitieren. Kanban tut das explizit, XP und Scrum tun das implizit. Die Frage ist nur : Was heißt eigentlich “schnell” oder “zeitnah”? Über welche Zeit reden wir da eigentlich?

Lead time

Die für den Kunden interessante Zeit ist eigentlich diese: “Wenn ich heute ein Feature in die Entwicklung gebe, wann kann ich es in der lauffähigen Software erkennen und testen?”. Diese Zeit nennt man in der Lean-Welt lead time. Ihre Einheit ist tatsächliche, abgelaufene Zeit (elapsed time). Sie enthält sowohl die Zeit für den Fertigungs-Workflow (also Analyse, Design, Unit-Test, Implementierung, Integration, etc.) als auch eventuelle Wartezeiten vor der Fertigung, weil das Team gerade noch andere Features zu entwickeln hatte.

Cycle time

Eine andere Zeit, die weniger für den Kunden und mehr für die Entwickler und deren Manager interessant ist, nennt man in der Lean-Welt cycle time. Ihre Einheit ist nicht tatsächlich abgelaufene Zeit (elapsed time), sondern der Rhythmus (engl. cadence), wie oft der Entwicklungsprozess ein Feature fertigstellt. Um den Unterschied zu verstehen, ein Beispiel: Ein GUI-Designer wird beauftragt, eine größere Anzahl bereits fertig entwickelter HTML-Seiten (z.B. 100 Stück) graphisch schön aufzubereiten. Sagen wir, er liefert jede Woche (5 Arbeitstage) 20 Stück, dann beträgt die cycle time pro HTML-Seite 2 Stunden (5 Tage mal 8 Stunden = 40 Stunden, dividiert durch 20 Stück, also 2 Stunden pro Stück).

Littles Gesetz und Work in Process

Wie stehen nun diese beiden Zeiten in Beziehung? Das fand John D.C. Little schon 1961 heraus. Damals formulierte er es so: In einem stabilen Wartesystem (Beispiel: Supermarkt) ist die durchschnittliche Anzahl von Kunden gleich dem Produkt aus Ankunftsrate und der durchschnittlichen Verweildauer im System.

Was heißt das, übertragen auf lead time und cycle time? Nun, die Ankunftsrate ist der Kehrwert der cycle time, die Verweildauer ist gleich der lead time und die durchschnittliche Kundenanzahl entspricht der Anzahl der Features, an denen das Team im Durchschnitt gleichzeitig arbeitet. In der Lean-Welt nennt man das work in process.

Also können wir Littles Gesetz so umstellen: lead time = work in process * cycle time.

Wenn der oben erwähnte GUI-Designer zu viele Aufträge hat, weil er für zu viele Kunden gleichzeitig arbeitet, ist seine work in process sehr hoch, z.B. befinden sich 100 HTML-Seiten bei ihm in Arbeit. Wenn ein Kunde nun eine neue Seite zum “Schönmachen” beauftragt, bekommt er sie erst nach einer lead time von durchschnittlich 5 Wochen zurück (100 Seiten x 2 Stunden/Seite, geteilt durch 40 Stunden pro Woche). Der Kunde wird unzufrieden sein, und der GUI-Designer sollte sich überlegen, ob er nicht mehr Aufträge ablehnen oder seinen Kollegen weitergeben sollte.

Handlungempfehlung

Was lernen wir daraus, wenn wir zu einem Software-Entwicklungsteam gehören oder ein solches managen? Um den Kunden zufrieden zu machen, sollte das Team die lead time optimieren. Das Einfachste ist, die work in process zu reduzieren, also einfach nicht an so vielen Sachen gleichzeitig zu arbeiten. Das Schwierigere ist, die cycle time zu reduzieren, also effizienter zu arbeiten. Dazu braucht es Methode. Wenn Sie Lust haben, zeige ich Ihnen , wie auch das geht. Rufen Sie mich an.

Anmeldung und Organisation übernimmt SIGS-DATACOM, auf deren Website Sie weitere Informationen über dieses Training finden können.

Ich freue mich, Sie in Köln zu sehen – das Training wird sehr spannend werden!

Hey, Uncle Bob is back at OOP,! For me this is very special because it was him who brought me to object oriented design/programming and to my first OOP conference, ever. And this was back in 1992 when I was a enthusiastic software developer, coding in C. Java did not exist in those days, design patterns were not published, there was no TDD – well, it was just the old days of poorly maintainable code!

Bob, when I came into your workshop about object oriented design at OOP, you started with a very simple example in C++ (at least, I thought it was): a car with an engine. You said something like this:

Bob: “OK, guys, lets define an accelerate() method on the car – what would be inside the body of this method?”. And my head started thinking. Somebody else: “The car should tell the carburator to increase the fuel to air ratio. And it should also tell the automatic transmission to shift one gear up!”

Bob: “OK, so Car::accelerate() calls Carburator::increaseFuelToAirRatio(), followed by Transmission::shiftUp(). Question to all of you: Is this a good design or a bad design?”

And poor me, inexperienced in OOD, could say neither yes nor no: “In fact, I don’t know!”.

Bob, you suddenly shouted “Of course, it is a BAD design, very bad design!”

Me: “Oh, why this?”

Bob: “What if you have a Diesel engine, without carburator? And: What if your car has an electric engine, without transmission?”

Me: “Hmmm… well, I guess, I would have to change the design significantly. Something like Thyristor::increaseElectricCurrent().”

Bob: “Exactly! So, how about introducing a neutral abstraction above all this? How about Engine::increasePower()? And with an intelligent Engine class that knows how to increase the power purely by itself? With nobody telling it how to do that?”

Me: “Aha!”

And so 1992 was the year when I became enthusiastic about object oriented design. Thanks a lot, Bob – I am really looking forward to see you again at this OOP. I guess, you won’t remember me but this is not a problem.

The RDFa plug-in allows you to expose relevant parts of the structure of your application as RDFa annotations in your views. Both domain model (non-information resources) and controller actions (information resources) can be described.

The plugin is still in its early stages, check out its interesting features which are described on the plugin page.

Ein Beispiel des Portals Indeed.com:

SCRUM and project management, AGILE and project management, PMI and project management Job Trends

SCRUM and project management jobs – AGILE and project management jobs – PMI and project management jobs

Good news today: Grails has a plug-in for this purpose – it is called the taxonomy plug-in. The developers of this plug-in say that it allows you to apply arbitrary hierarchical categorisation (Taxons) to domain objects. Here is an example of the basic usage:

def book = Book.get(1)
// Add the book to the Non-fiction > Autobiography category
book.addToTaxonomy(['Non-fiction', 'Autobiography'])
 
def autobiographies = Book.findAllByTaxonomyFamily(
    ['Non-fiction', 'Autobiography']
)

There is support for arbitrary nesting of Taxons (categories) within unlimited taxonomies, and taxonomies are domain class independent.

So the category “Local” on Author can also be used on Book.

However, you can have different taxonomy graphs aside from the default one, so you might have a taxonomy graph “Location” storing the names of states and cities, and another taxonomy graph “Company type” – and objects having categories in both graphs.

Release 0.1 of the taxonomy plug-in is “alpha” grade. It does not support polymorphism. So querying objects by taxonomy requires you to query the specific class type. This will be resolved in the next release. Also, it does not do caching so it isn’t going to be blazingly fast. Developers say that this will come soon.

Have fun and visit the plug-in page on grails.org.

This plugin helps you to define a fixture, that is a defined set of data used for testing. The plugin defines a DSL in which you can express your need for data. Example:

fixture {
    guillaume(Author) {
        name = "Guillaume Laforge"
    }
    dierk(Author) {
        name = "Dierk Koenig"
    }
    gina(Book) {
        title = "Groovy In Action"
        authors = [guillaume, dierk]
    }
}

Or a little shorter:

fixture {
    guillaume(Author, name: "Guillaume Laforge")
    dierk(Author, name: "Dierk Koenig")
    gina(Book, title: "Groovy In Action", authors: [guillaume, dierk])
}

Then, in your test case, you will want to load that fixture, like this:

class GinaTests extends GroovyTestCase {
    def fixtureLoader
 
    void testFinderMethod() {
        fixtureLoader.load("gina")
        def gina = Book.findByTitle("Groovy In Action")
        assertNotNull(gina)
        assertEquals(2, gina.authors.size())
    }
}

Pretty simple, isn’t it? Find out more about how to install and use the Fixtures plugin on its plugin page at grails.org.

A grails implementation of MonsterID: a method to generate a unique monster image based upon a certain identifier (user id, email address, whatever). It can be used to automatically provide personal avatar images in blog comments or other community services.

You can find this plugin (as usual) on grails.org.

Out of the box it:

• renders a field using a UI element appropriate for the property type. Constraints are used to set maximum lengths etc.
• automatically renders tags for fields, from i18n message bundles
• renders “required” indicators if the field is nullable:false and/or blank:false
• renders errors adjacent to the field that had the error
• renders the current value as appropriate

This is all done by building on top of Grails existing tags, so all the regular tag attributes are supported where possible.

Here’s an example of how you can render all this for a bunch of bean properties:

<bean:withBean beanName="form">
    <bean:field property="firstName">
    <bean:field property="lastName">
    <bean:field property="company">
    <bean:field property="email">
</bean:withBean>

You can find more elaborate examples as well as instructions for use on the plugin page.

Bug description: When a user makes a payment, Paypal notifies the site with a so-called instant payment notification. The code in PaypalController.notify() was wrong so that an error code 404 was returned to Paypal. Paypal retried the notification several times and finally gave up. The plugin processed the notification properly, though.

I fixed this bug today and released the corrected Paypal plugin as version 0.5.

You can find more info about the plugin on the plugin page at grails.org.

This is an interesting phenomenon that I am trying to study and understand. Maybe, it is possible to generate something entirely new.

However, at least one plug-in developer for Grails seems to think differently. See for yourself:

This plugin provides an ‘automatic’ component-like rendering infrastructure to Grails. It combines the ease of use of scaffolding with the flexibility to change the resulting views via custom renderers. This also allows you to change what tags you use to render an object without having to worry about consistency across views. Write it once, and be done with it!

What do you think – is this plug-in worth a try?

It is quite easy to route messages. For example, write a Grails service like this:

class MyService {
    def myMethod(fooBarText) {
        log.info “Got text: ${ fooBarText }”
    }
}

Then, using Camel’s bean integration, you can deliver messages from an in-memory queue directly to that Grails service:

from(“seda:my.queue”).filter {
    it.in.body.contains(“FooBar”)
}.to(“bean:myService?methodName=myMethod”)

Cool, isn’t it? As usual, you can find more info on the plugin page on grails.org.

There are three ways to define security mappings – see Securing URLs for more details. This tutorial uses the Requestmap approach. To use Controller annotations, use this tutorial and to specify security mappings using the standard Spring Security approach use this tutorial.

Good Luck!