Schöner Cartoon von Ralph Ruthe zum Thema Teamfähigkeit. Das freut vor allem die Bremer unter uns (zu denen auch ich zähle). Für diese Zielgruppe habe ich (na ja – eigentlich Haschi) noch einen Cartoon gefunden.
“Der Hahn ist nicht teamfähig …”
08. Januar 2010Scrum: Ein Kreislauf der Verantwortung
24. Dezember 2009In Scrum und anderen agilen Vorgehensweisen und Frameworks spielt die Verantwortung eine große Rolle. Der Begriff “Verantwortung” ist eine mögliche Übersetzung des englischen Begriffs “commitment”. Die andere Übersetzung, die ich im Zusammenhang mit agilen Vorgehensweisen gerne verwende, ist “Verpflichtung”. Beide Begriffe meinen Ähnliches, aber eben nicht dasselbe. Die Verpflichtung zielt meinem Verständnis nach in der Hauptsache auf die termingerechte Lieferung des gemeinsam festgelegten Ergebnisses ab. Verantwortung ist für mich der weitaus stärkere Begriff, umfasst er doch neben der konsequenten Ergebnisorientierung auch die Sorge für den Prozess und das Team – und noch einige andere Dinge, die ich zu einem “Scrum-Verantwortungskreis” zusammengefasst habe:
Der Scrum-Verantwortungskreis
Verantwortung für das Product Backlog
Der Product Owner ist verantwortlich für die fachliche Beschreibung des Produkts. Der Funktionsumfang des Produkts wird durch die Backlog Items festgelegt, die gemeinsam das Product Backlog bilden. Auf die Frage, was ein “gutes” Backlog Item darstellt, gibt es viele “richtige” Antworten. Fest steht, dass alles, was das Produkt ausmacht, beschrieben und für das Team sichtbar und nachvollziehbar sein muss. Ob nicht funktionale Anforderungen, beispielsweise Performanz- oder Sicherheitsaspekte, als Backlog Items beschrieben werden sollen, ist letztendlich Geschmackssache. Viel wichtiger ist, dass diese Aspekte überhaupt berücksichtigt werden, oder anders ausgedrückt: dass sich jemand für diese Aspekte verantwortlich fühlt.
Verantwortung in der Schätzklausur
In der Schätzklausur bestimmt das Team die Größe der Backlog Items – nach bestem Wissen und Gewissen und in der Erwartung, dass sich die Größenschätzungen mit zunehmendem Erkenntnisgewinn verändern können. Zwei Aspekte sind beim agilen Schätzen wichtig: Zum einen schätzt das Team die Backlog Items selbst. Die Teammitglieder müssen die Backlog Items später umsetzen, deshalb sollen sie so früh wie möglich eine Vorstellung über die Inhalte dieser Items entwickeln und eine realistische Abschätzung der Größe treffen. Die Schätzung des Teams kann vom Scrum Master oder dem Product Owner nur argumentativ beeinflusst werden. Das letzte Wort hat immer das Team. Logische Schlussfolgerung: Das Team trägt die Verantwortung für dir Schätzung – was nicht bedeutet, dass der Schätzwert in Stein gemeißelt ist. Auch hier gilt: Veränderung ist etwas ganz Natürliches.
Verantwortung für das Sprint Backlog
Eine erfolgreiche Schätzklausur zeichnet sich durch ein hohes Maß an Kommunikation aus. Das Team diskutiert erste Implementierungsstrategien, um auf dieser Basis einen Schätzwert bestimmen zu können. Dazu muss es die fachlichen Anforderungen des Backlog Items möglichst gut verstehen. Aus diesem Grund nimmt der Product Owner (eventuell gemeinsam mit anderen Kundenvertretern und Experten) an der Schätzklausur teil. In der Diskussion über ein Backlog Item entwickelt sich ein gemeinsames Verständnis der fachlichen Anforderungen. Mit diesem Wissen und dem durch die Sprintlänge abgesteckten zeitlichen Rahmen ist das Team nun in der Lage, gemeinsam mit dem Product Owner eine Menge von Backlog Items auszuwählen, die im Rahmen des kommenden Sprints umgesetzt werden sollen. Diese Auswahl findet ihren Ausdruck im Sprint-Ziel, auf dessen Erreichung sich das Team verpflichtet (da ist sie: die andere Bedeutung von “commitment”!).
Verantwortung für die Aufgaben (Tasks)
Jetzt geht es richtig los: Aus den (beispielsweise in Form von User Stories) fachlich formulierten Backlog Items werden vom Team einzelne Aufgaben extrahiert. Diese Handlungsanweisungen beschreiben technisch und/oder fachlich, was konkret zu tun ist, um das Sprint-Ziel (genauer: das zugehörige Backlog-Item) zu erfüllen. Wenngleich das “Was” nun konkret beschrieben ist, so hat das Team bei der Frage nach dem “Wie” immer noch einen großen Handlungsspielraum. Dieser wird begrenzt durch die im Projektkontext geltenden Architekturvorgaben, Programmierrichtlinien und Standardtechnologien und nicht zuletzt durch das kollektive Wissen des Teams. Auch wenn der organisatorische Rahmen dem Team ein wenig “Wie”-Verantwortung abnehmen kann, so muss das Team immer in der Lage sein, die getroffenen Entscheidungen zu argumentieren. Das fällt den meisten Mitgliedern agiler Teams jedoch recht leicht, weil die Verantwortung kollektiv leichter getragen werden kann als von einem einzelnen Softwarearchitekten.
Verantwortung im Daily Scrum
Das Daily Scrum dient der täglichen Synchronisation und der kollektiven Fortschrittskontrolle (in Form der Burndown Charts). Hier übernimmt das Team Verantwortung für den Fortschritt. Ein Daily Scrum ist zugleich eine Mini-Retrospektive: Das Team reflektiert über die vergangenen 24 Stunden. Es überprüft, ob das gesteckte Zwischenziel (in Form einzelner Aufgaben) erreicht wurde, forscht beim Nichterreichen (kurz!) nach den Ursachen und bringt geeignete Maßnahmen auf den Weg, um das Ziel am Ende des Sprint erreichen zu können. Im Daily Scrum tritt die Verantwortung der einzelnen Teammitglieder oft sehr deutlich zutage. Nicht selten führt der Druck der Verantwortung zu Rechtfertigungen einzelner Teammitglieder, die erklären wollen, warum sie nicht so weit sind, wie sie eigentlich sein sollten (besser: wollten). Hier ist der Scrum Master gefragt, um diese Art von Diskussionen in eine ergebnisorientierte Richtung zu lenken. Es hat sich bewährt, den agilen Grundwert “Fokussierung” im Gedächtnis der Teammitglieder regelmäßig zu reaktivieren. Die Konzentration auf die anstehenden (hier auch im Sinne von “an dem Sprint Backlog stehenden”) Aufgaben wirkt manchmal Wunder.
Verantwortung im Sprint Review
Im Sprint Review erneuert das Team seine Verantwortung für das Sprint-Ziel, die es zu Beginn des Sprints übernommen hat. Anhand des (potentiell produktiv nutzbaren) Sprint-Ergebnisses kann das Team zeigen, was es in diesem Sprint geleistet hat. Dank des gemeinsam mit dem Product Owner festgelegten Sprint-Ziels sollte das Ergebnis nahezu deckungsgleich mit den fachlichen Anforderungen sein – ein “so habe ich das nicht gewollt!”-Erlebnis bleibt den agilen Teams meistens erspart. Da im Sprint Review ein funktionierendes Produkt vorgestellt wird, können die Kunden ihre Anforderungen und Ideen am “lebenden Objekt” messen, gegebenenfalls verfeinern oder verändern bzw. das Team auf Missverständnisse bezüglich der Backlog Items hinweisen. Auch hier gilt: Wer rechtzeitig und regelmäßig miteinander kommuniziert, der wird im Sprint Review eher positiv überrascht.
Verantwortung in der Retrospektive
Während sich im Sprint Review alles um das Produkt dreht, so steht in der Retrospektive der Softwareentwicklungsprozess im Mittelpunkt. “Wie können wir das agile Handwerkszeug noch geschickter einsetzen, um die gemeinsam erkannten Probleme auszumerzen?”, fragt sich das Team. Dem Erkenntnisgewinn folt eine Priorisierung der Hindernisse, um schließlich für die am höchsten priorisierten Probleme geeignete Gegenmaßnahmen zu entwickeln und zu etablieren. Damit bietet sich dem Team die Möglichkeit, das eigene Arbeitsumfeld selbst zu gestalten. Das (und natürlich die vom Produkt begeisterten Kunden) ist der Lohn für die viele Verantwortung, die das Team im Laufe eines Scrum-Projekts übernimmt. Und da geteilte Verantwortung nur halb so schwer wiegt, kann Verantwortungsübernahme in agilen Projekten tatsächlich Spaß machen. Aus Verantwortung und Spaß entsteht dann nicht selten
Spaß an der Verantwortung
… und spätestens dann hat sich die Entwicklungsmannschaft zu dem eigenverantwortlichen agilen Team entwickelt, von dem in der agilen Literatur oft die Rede ist. Der Scrum Master eines solchen Teams muss nur noch selten an die agilen Werte und die Einhaltung der Spielregeln erinnern. Das macht ihn nicht arbeitslos – es sei denn, das Impediment Backlog ist leer. Aber das wäre ja nun wirklich zu schön, um wahr zu sein …
Geschichten vom Scrum – live
17. Dezember 2009Am 17.12.2009 war ich zu Gast in der Fachbuchhandlung Lehmanns in Hamburg, um in einer vorweihnachtlichen Märchenstunde aus meinem Buch “Geschichten vom Scrum” vorzulesen. Trotz Schneefall (zum ersten Mal in diesem Winter) und Straßenglätte hatten sich ca. 30 Zuhörer eingefunden, um bei Spekulatius und Schokoladenherzen zu erfahren, wie eine bunt zusammengewürfelte Truppe in agiler Manier eine Drachenfalle baut. Die anschließenden Diskussionen zeigten, dass in vielen Unternehmen die Vorteile eines agilen Vorgehens immer noch angezweifelt werden. Das ist wohlbekannt und lässt sich meiner Meinung nach nur im persönlichen Gespräch und durch erfolgreiche Taten entkräften. Die zweite Erkenntnis, die jedoch auch nicht neu ist: Scrum und andere agile Frameworks sind keine Wunderwaffen. Sie machen aber die Problembereiche in Projekten (und Organisationen) offensichtlich. Wer das als Segen betrachtet, und nicht etwa als Fluch, dem kann die konsequente Anwendung agiler Werte, Prinzipien und Praktiken zu erfolgreicheren Projekten verhelfen. Alle anderen müssen zunächst einmal erkennen, dass eine größere Transparenz etwas Gutes, Zielführendes ist. Mike Cohn hat die fünf Schritte zur erfolgreichen Einführung agiler Vorgehensweisen zu dem Akronym ADAPT zusammengefasst:
- Awareness – das Bewusstsein, dass der derzeit verwendete Prozess nicht die gewünschten Ergebnisse erbringt
- Desire – das Verlangen, die bestehenden Probleme mit Hilfe agiler Methoden zu adressieren
- Ability – die Befähigung, eine agile Methode erfolgreich einzusetzen
- Promotion – das (interne) Marketing für die agile Vorgehensweise in Form von Erfahrungsberichten
- Transfer – die Ausweitung der agilen Methoden auf andere Unternehmensbereiche (aus Sicht einer IT-Projektabteilung)
(aus Mike Cohn: Succeeding with Agile)
Was bedeutet das für die “agilen Zweifler”? Nun, sie sollten sich zunächst auf einer dieser Stufen einordnen – um dann zu überlegen, wie sie die nächste Stufe erreichen. Nein, das ist kein Wasserfall-Modell! Es ist eher vergleichbar mit den Lernstufen Shu, Ha und Ri der japanischen Kampfkünste. Ich muss wissen, wo ich stehe, um dorthin zu kommen, wo ich hin möchte. Klingt so einfach…
Geschichten vom Scrum
28. November 2009
In der agilen Welt bedient man sich gerne der uralten Tradition des Geschichtenerzählens, um Wissen zu vermitteln und Inhalte erlebbar zu machen. Menschen lieben Geschichten, und Softwareentwickler bilden da keine Ausnahme.
Diese Idee greife ich mit den »Geschichten vom Scrum« auf. Anhand eines fiktiven Projekts illustriere ich die Werte, Konzepte und Praktiken, die agile Softwareentwicklung und agiles Projektmanagement ausmachen:
König Schærmæn der Weißnichtwievielte hat eine Vision: Er möchte die beste und flexibelste Drachenfalle aller Zeiten entwerfen und bauen lassen. Um diese Aufgabe zu meistern, lässt er eine geeignete Mannschaft zusammenstellen. Unter Anleitung eines Einhorns aus dem Lande Scrum macht sich eine Gruppe ganz normaler Märchengestalten ohne agile Vorkenntnisse an die Arbeit. Es gibt viel zu lernen: Das Handwerkszeug von Scrum und der Drachenfallenbau wollen beherrscht und zwischenmenschliche Probleme gemeistert werden. Am
Ende entsteht nicht nur die gewünschte Drachenfalle, sondern auch ein erfolgreiches Scrum-Team.
Als Leser begleiten Sie die Märchengestalten auf ihrem Weg zum Projekterfolg. Dabei unterstützen Sie die ergänzenden Erläuterungen
und Kommentare des Einhorns. Am Ende wissen Sie nicht nur, aus welchen Elementen Scrum besteht, sondern auch, wie man diese Elemente erfolgreich einsetzt.
Die Konferenz des Jahres: XP Days Germany
28. November 2009Mein Urteil steht fest: Die XP Days Germany 2009 in Karlsruhe war meine persönliche Lieblings-Konferenz dieses Jahres. Warum?
Beginnen wir mit dem Call for Papers. Das offene Verfahren, in dem die Einreichungen von allen kommentiert und bewertet werden können, führte iterativ zu besseren (weil verständlicheren) Sessionbeschreibungen. Das half zunächst einmal dem Programmkomitee bei der Auswahl der Sessions. Es half aber insbesondere auch den Teilnehmern, weil diese aus den langen Beschreibungen sehr gut ablesen konnten, was sie in den verschiedenen Sessions erwartet. Das ist ein großer Vorteil gegenüber anderen Konferenzen, bei denen die Sessionbeschreibungen sehr kurz sein müssen (Beispiel OOP: 500-600 Zeichen). Allerdings verhindert auch das offene Einreichungsverfahren der XP Days nicht das klassische Klüngelverhalten (”Den Einreicher kenne ich – der Vortrag muss gut sein”). Dieses tritt allerdings in deutlich abgeschwächter Form auf und ist vor allem transparent (weil jeder Kommentar für alle sichtbar ist).
Das Programm kann ich nur als hochkarätig bezeichnen – und das trotz des krankheitsbedingten Ausfalls einiger Sprecher. Auf diese Weise bekam ich die Chance, meinen Pecha-Kucha-Vortrag “Mein agiler Koffer” noch einmal halten zu dürfen. Der Flurfunk nach den drei Pecha-Kucha-Sessions lässt sich in folgender Aussage zusammenfassen: Pecha Kuchas sind kurzweilig und schmeicheln das Auge mit schönen Bildern und wenig Text. Allerdings ist der rote Faden dieser Vorträge nur schwer erkennbar. Wenn ich auf meinen eigenen Vortrag zurückblicke, dann kann ich das bestätigen. Da ich dieses Format lieben gelernt habe, nehme ich die Kritik zum Anlass, um an genau diesem Punkt anzusetzen und die Kernaussage (mehr als eine kann es in 6 Minuten und 40 Sekunden kaum geben) noch besser herauszuarbeiten.
Insgesamt hat mich die Mehrzahl der Vorträge vor allem deshalb überzeugt, weil sie Denkanstöße gegeben haben, anstatt vermeintliche Patentlösungen zu postulieren. Genau diese Aufforderung zum Blick über den Tellerrand ist es, was ich von Fachkonferenzen erwarte. Andere Teilnehmer waren mit diesen ergebnisoffenen Sessions weniger zufrieden, aber allen kann man es wohl kaum recht machen.
Jens Coldewey hat auch ohne seinen Vortragspartner Henning Wolf (lag krank zu Hause im Bett) das Problem der Wissensinseln in Projekten und Unternehmen anschaulich aus verschiedenen Perspektiven dargestellt und die Diskussion darüber eingeleitet, wie man diese Inseln verhindern kann.
Roman Pichler ging der Frage nach, was eigentlich vor dem ersten Sprint passiert. Im wesentlichen ging es in seinem Vortrag um die Frage, wie eine gute Vision aussieht. Diese Vision vor Augen, können dann die eigentlichen Sprints erfolgreich in Angriff genommen werden. Sehr gut gefallen hat mir sein Bild einer Produktvision, das er mit der ersten Skizze eines Gemäldes verglich. In der Skizze sind alle wesentlichen Inhalte des Bildes bereits angedeutet, aber nur knapp umrissen. Anschließend macht sich der Maler dann an die Ausgestaltung – und nichts anderes passiert in den Sprints. Eine solche Vision lässt sich übrigens auch mit Hilfe der Scrum-”Bordmittel” erzeugen.
Spannend war der (gelungene) Versuch von Martin Heider und Jens Coldewey, in nur 30 Minuten das Konzept der Story Maps anhand eines praktischen Beispiels (Artikeleinreichung beim OBJEKTspektrum) zu erläutern. Die Grundideen haben beide verständlich vermitteln können, aber für die erfolgreiche praktische Umsetzung kommt man nicht umhin, die Ärmel hochzukrempeln und es selbst zu versuchen.
Die Keynote von Alistair Cockburn war kurzweilig. Seiner Meinung nach gibt es drei wichtige Ingredienzen für erfolgreiche agile Softwareentwicklung im 21. Jahrhundert: Craft, Cooperative Games und Lean Processes. Die Craftsmanship-Bewegung ist nicht neu, aber interessant war die Parallele zu den drei Ebenen des Lernens aus den japanischen Kampfkünsten: “Shu” bezeichnet die erste Stufe, auf der die Grundlagen einer Technologie traditionell gelernt werden. Auf der zweiten Stufe namens “Ha” erweitert der Lernende seine Sichtweise, hinterfragt das Gelernte und sucht nach neuen Wegen – bricht also mit der Tradition. Auf der dritten Stufe – “Ri” – handelt man intuitiv, ohne sich bewusst auf das Erlernte zu beziehen. Auf dieser Stufe entstehen neue Techniken aus der Kombination bestehender Ansätze.
Sehr anregend war auch der Vortrag von Markus Wittwer. Er stellte Spiral Dynamics vor – ein Modell über die Wertentwicklung von Menschen und Kulturen. Den verschiedenen Stufen ist jeweils eine Farbe zugeordnet. Aus der persönlichen Einordnung auf dieser Farbskala und der Einordnung der Organisation (Arbeitgeber, Kunde) ergibt sich ein überschaubares Wertebild – und eine mögliche Erklärung dafür, warum man oft das Gefühl hat, dass manche Dinge nicht so laufen, wie man es gerne hätte.
Christoph Mathis begab sich auf die Suche nach den idealen Skills, Arbeitsweisen und Umgebungen für agile Teams. Auch hier spielte die Software Craftsmanship eine große Rolle. Dieser Professionalität in der Softwareentwicklung hat sich auch die deutsche Initiative clean-code-developer.de verschrieben. Zur Analyse der agilen Skills haben Brian Marick et al. die sieben Säulen agiler Teams definiert.
Am Community Day konnte ich leider nicht teilnehmen. Den Tweets nach zu urteilen, habe ich einen spannenden interaktiven Tag verpasst.
Ich freue mich schon auf die XP Days Germany 2010, die wieder heimatnah in Hamburg stattfinden werden.
Prinzen und Aschenputtel: Anatomie eines Scrum-Teams
27. November 2009Zum letzten Mal habe ich die Urfassung des agilen Märchens “Prinzen und Aschenputtel” präsentiert. Jetzt gibt’s die “Geschichten vom Scrum” als Buch. Auf den XP Days konnte ich das erste Exemplar in den Händen halten – immer wieder schön… Aber worum ging es in meinem Vortrag?
In der agilen Literatur ist es fast wie im Märchen: Da werden die besten Mitarbeiter einer Firma zusammengerufen, um gemeinsam das beste Produkt aller Zeiten in vielen kleinen Schritten herzustellen – bei ständiger Zufriedenheit des Kunden. Das Team arbeitet selbstbestimmt und zielorientiert, man hilft sich gegenseitig, und alles wird gut. In der Praxis kann man froh sein, wenn man zu Projektbeginn überhaupt ein Team hat. Die Besten darf man höchstens ab und zu als Experten zu Rate ziehen. Dafür findet man die gesamte Bandbreite an Charaktereigenschaften vor: Prinzen – heimliche Anführer unter Gleichen; Ritter in goldener Rüstung – ohne sie läuft nichts, sie schlagen den Weg frei; das tapfere Schneiderlein – mit ihm ist man gut (?) beraten; Aschenputtel – das tiefe stille Wasser. Und viele weitere sonderbare Gestalten.
Lassen Sie sich verzaubern und erleben Sie, wie mit Hilfe eines Einhorns aus dem wunderbaren Land Scrum aus diesen Individuen ein schlagkräftiges Team geformt werden kann.
“Mein agiler Koffer” – Reisetipps mit Pecha Kucha
26. November 2009Weil einige Referenten der XP Days 2009 grippebedingt absagen mussten, sprang ich kurzerhand ein und packte wie zuvor auf der W-JAX im Rahmen eines Pecha-Kucha-Vortrags meinen agilen Koffer. Dieses Format macht zunehmend Spaß. Allerdings gibt es noch viel “Luft nach oben”. Die nächste Herausforderung besteht darin, die zentrale(n) Nachricht(en) des Vortrags (bei 20 Folien kann es davon nicht allzu viele geben) deutlicher herauszuarbeiten. Und vielleicht sollte ich nicht ganz so schnell reden wie einst Dieter Thomas Heck…
W-JAX 2009: Brezn, Brogrammiersprachen, BPM
12. November 2009Auch wenn morgen offiziell der letzte W-JAX-Tag ist: Am Donnerstagabend rüstet sich das Gros des IT-Volks zur Heimreise. Vier Tage W-JAX liegen nun hinter mir, und der Blumenstrauß an Erfahrungen und Informationen ist bunt.
Am Montag bot der Agile Day eine gesunde Mischung aus Anwenderbeiträgen (mobile.de, XING) und Expertenvorträgen (Coldewey, Wolf, Eckstein). Persönlicher Höhepunkt war die Pecha-Kucha-Session “Mein agiler Koffer” – mein erstes Pecha Kucha!
Ein Highlight am Dienstag war die kurzweilige Keynote von Ted Neward. Er hat den bis auf den letzten Platz gefüllten großen Ballsaal des Westin Grand Hotels davon überzeugen können, dass uns die Zukunft eine Vielfalt an Programmiersprachen bescheren wird, und dass die Diskussion über und die Arbeit mit diesen Sprachen eine Bereicherung darstellt. Derart inspiriert ließ ich mich auf die Reise von Java nach Groovy ein – fühlte mich am Reiseziel aber nicht sonderlich heimisch. Danach wollte ich mich von Eberhard Wolff eines Besseren belehren lassen, was den Entwurf von Enterprise-Java-Anwendungen angeht. Der Vortrag war sehr Spring-lastig (Zitat: “Ich kann leider nur Spring”). Eigentlich hätte ich es wissen müssen. Leider brachte er nicht viel Neues, und einige der vorgestellten “typischen Fehler” waren nicht ganz schlüssig – was aber gleichermaßen für die vorgeschlagene Lösung galt. “S.O.S. – Mein Chef sagt, wir brauchen einen ESB!”, rief uns Thilo Frotscher in seinem Vortrag entgegen. Ich hatte erwartet, dass er entweder für oder gegen einen ESB plädiert. Sein Vorschlag aber war, eine ESB-artige Architektur aus Open-Source-Komponenten im Eigenbau zu erstellen. Zumindest eine überraschende Variante. Der Tag klang angenehm und anregend mit Stefan Zörners kritischen Betrachtungen von Zertifizierungen für IT-Architekten aus. Allein für den Titel “Certified Quacksalber” hätte Stefan einen Sonderpreis verdient.
Die Reise in die Groovy-Welt war wie gesagt nichts für mich. Das sollte sich am Mittwoch beim Ausflug nach Scala ändern. Arno Haase ließ es sich nicht nehmen, seine Einführung in die objektorientiert-funktionale Sprache komplett ohne Folien und nur mit einer IDE bewaffnet zu gestalten. Das verlieh dieser Veranstaltung (ungewollt?) eine interaktive Note – und zwar immer dann, wenn die IDE einen Compiler-Fehler meldete und der gesamte Saal den Code inspizierte, um den Fehler zu finden. Merke: Scala braucht mehr Klammern, als manch einer denkt. Dermaßen Scala-gestärkt konnte ich sogar der Keynote des Scala-Vaters Martin Odersky folgen, der im Schnelldurchlauf die Sprache vorstellte und einen Ausblick auf deren Zukunft gab. Sehr speziell, aber sehr interessant war der Vortrag von Emmanuel Bernard über den Bean-Validation-Standard (JSR-303). Dieses Validation-Framework ist technisch wirklich clever umgesetzt. Es ist ohnehin immer faszinierend, wenn man einem echten Experten (und Spec Lead) lauschen kann, der voll im Thema drin ist. Dann war ich dran, um über den Sinn und Unsinn von Standards zu referieren. Anschließend belohnte ich mich mit der schönen Zusammenfassung der agilen Aufwandschätzung, ansprechend in Szene gesetzt von Henning Wolf und Andreas Havenstein.
Am Donnerstag habe ich dann gelernt, was man mit Scala so alles anstellen kann. Beispielsweise lässt sich elegant (zumindest für den Anwender) eine domänenspezifische Sprache zum angenehmeren Umgang mit OSGi-Services definieren. Der von Heiko Seeberger vorgestellte Ansatz (ScalaModules) hat mich überzeugt – soweit man nach 30 Minuten Folien und Kommandozeilen-Demos überhaupt von Überzeugung sprechen kann. Anschließend stand für mich der BPM Day auf dem Programm. Jakob Freund zeigte gewohnt fundiert und kurzweilig seine Sicht auf die BPM-Welt - verlor aber das Thema seines Vortrags (”BPMN 2.0 – Wird BPEL nicht gebraucht?”) zunehmend aus den Augen und ließ zudem Bernd Rücker kaum zu Wort kommen 
Volker Stiehl beschränkte sich in seinem Vortrag nicht darauf, die integrierte BPM(N)(2.0)-Plattform namens “Composition Environment” seines Arbeitgebers SAP vorzustellen, sondern verdeutlichte auch sehr anschaulich, das zum Entwerfen einer funktionierenden BPM/SOA-Landschaft mehr gehört als ein wenig Uhu-Code zwischen Process Engine und ESB. Das ergänzte Jakobs BPM-Aufklärungsarbeit um den SOA-Aspekt. Damit nicht genug, machten Jo und ich in unserem Vortrag über die “Königskinder” Business Process Engine und Business Rule Engine deutlich, das es für die Familienzusammenführung kein Patentrezept, dafür aber viel zu beachten gibt. Waren diese vielen kritischen Hinweise am BPM Day ein frustrierendes Zeichen dafür, dass BPM und SOA nicht funktionieren? Mitnichten! Sie zeigen nur, dass man diese Themen – wie alle anderen IT-Themen auch – ernsthaft betreiben muss. Schließlich machten Jo und ich uns sofort auf den Weg zu dem großen Flughafen in der Nähe von München, um unseren Flieger gen Hamburg zu erwischen. Jetzt gibt’s wieder Fischbrötchen statt Brezn und Astra statt Weißbier.
Königskinder: Wie Process Engine und Rule Engine zusammenfinden
12. November 2009“Sie konnten zusammen nicht kommen, das Wasser war viel zu tief” – so heißt es im Lied von den zwei Königskindern. Mit der Integration von Business Process Engine und Rule Engine scheint es sich ähnlich zu verhalten. Obwohl beide Systeme einander ideal ergänzen, gestaltet sich die Zusammenführung mitunter schwierig. Dieser Vortrag sortiert die Begriffswelten und diskutiert Integrationsmuster.
Mehr Standards = Bessere Software?
11. November 2009Der Ruf nach Standards ist in IT-Projekten an der Tagesordnung. Es klingt ja auch verlockend: eine standardisierte Architektur, Software und/oder Systemlandschaft. Sollten sich da nicht alle Probleme in Luft auflösen? Dieser Vortrag wirft aus verschiedenen Blickwinkeln kritische Blicke auf Standards in allen Bereichen der Informationstechnologie (und darüber hinaus).