Agile Methoden wie Scrum oder Kanban  etablieren sich zunehmend als Alternative zu klassischen Vorgehensmodellen in der Softwareentwicklung. Ist das alles nur ein großer Hype oder steckt mehr dahinter? Gibt es vielleicht sogar einen echten Business Case? Anhand einer idealisierten Geschichte soll verdeutlicht werden, welche Chancen die Agilität bietet und warum sich ein Umstieg rechnet.

In der aktuellen Ausgabe des Business Technology Magazins beschreiben Andreas und ich anhand einer fiktiven Geschichte, warum sich Agilität auch aus finanzieller Sicht für Unternehmen lohnt.

Die 4 Kernthesen für den Business Case für Agilität sind dabei:

1. Schneller geschäftlicher Nutzen und Time to Market
2. Weniger Fehl- und Blindleistungen
3. Risikomanagement von komplexen Situationen
4. Hohe und nachhaltige Qualität

Den vollständigen Artikel kann man von unserer Webseite herunterladen: Business Case für Agilität

Bei Scrum gibt es die Rolle des Projektleiters nicht mehr. Die meisten Befugnisse und Verantwortlichkeiten haben sich auf die drei Rollen Product Owner, Scrum Master und Team verteilt. Wie geschieht das im Bereich der Teamzusammenstellung? Dabei sind folgende Teilaufgaben zu betrachten:

• Initiale Teamzusammensetzung
• Fehlende Fähigkeiten im Team
• Vergrößern des Teams (um Velocity zu steigern)
• Verkleinern des Teams (bei „Leerlauf“)
• „Low Performer“ und „Störenfriede“ identifizieren und ausschließen

Initiale Teamzusammensetzung
Die Zusammenstellung des Teams bei Projektstart kann nicht durch das Team selber ge­sche­hen, das gibt es zu diesem Zeitpunkt noch gar nicht. Durch seine Budget­ver­ant­wort­lich­keit hat der Product Owner natürlich einen sehr starken Einfluss, aber die genaue Entscheidung liegt sinnvollerweise beim Scrum Master. Er sollte darauf achten, dass das Team gerade in der ersten Zeit funktionieren kann, sowohl von den fachlichen als auch den sozialen Fähigkeiten der einzelnen Teammitglieder.

Die hier auftauchende Frage wie eine gute Zusammensetzung des Projektteams über den gesamten Projektverlauf aussieht, halte ich für sehr spannend würde aber den Rahmen sprengen. Diese werde ich in einem zukünftigen Artikel beleuchten.

Fehlende Fähigkeiten
Sollten im Team für das Projekt benötigte Kompetenzen fehlen, wird das durch das Team sehr schnell als Hindernis artikuliert. Meist erfolgt dies schon in den Daily Scrums, spätestens aber in den Retrospektiven. Es ist dann die Aufgabe des Scrum Masters dafür zu sorgen das Team mit den fehlenden Fähigkeiten auszustatten. Da bieten sich dem Scrum Master unterschiedliche Handlungsoptionen:

• Veränderung der Teamzusammensetzung
• Schulung/Coaching von Teammitgliedern
• Hinzuziehen eines Spezialisten

Vergrößerung des Teams
Hier geht es um die Entscheidung das Team zu vergrößern um die Velocity langfristig zu steigern. Der Grund kann eine sinkende (oder stagnierende) Velocity, der ansteigenden Termindruck des Projekts von außen oder einfach freie Mitarbeiterkapazitäten die in laufende Projekte eingebunden werden sollen sein.

Dieser Fall beschäftigt vor allem den Product Owner und das Team. Der Product Owner muss immer zwischen einer steigenden Velocity und den höheren Kosten (durch ein größeres Team) abwägen. Das Team wiederum kann beurteilen ob und in welcher Form weitere Teammitglieder überhaupt sinnvoll helfen.

Verkleinerung des Teams
Im Projektgeschäft kommt es immer wieder zu „Leerlauf“. Die Gründe hierfür sind sehr unterschiedlich, z.B. sind alle weiteren Aufgaben abhängig von einer Spezialistenaufgabe und sind so blockiert, zum Sprintende ist das Sprint-Backlog leer oder das Projekt­ende zeichnet sich gar durch eine leeres Product-Backlog ab. Auch lassen Projekte meist nur eine begrenzte Parallelisierung zu. Diese kann im Laufe des Projekts variieren und so „Leerlauf“ erzeugen. Dabei kann es sich beim „Leerlauf“ um ein spontanes Phänomen handeln oder er ist von systematischer Natur.

Erste Aufgabe ist es, zu erkennen, dass ein systematischer „Leerlauf“ vorliegt. Hier sind Team und Scrum Master gefordert. Dann ist eine passende Lösung zu finden, bevorzugt (und auch in den meisten Fällen möglich) im bestehenden Team, z.B. durch Neuschneiden der Aufgaben um die Spezialisten-Engpässe zu umgehen.

Aber gerade wenn es Richtung Projektende geht oder eine bisher genutzte hohe Parallelisierbarkeit entfällt, kann es Sinn machen, ein großes Team zu verkleinern.

Die Frage, welche neue Teamgröße sinnvoll ist, kann evtl. noch das Team entscheiden. Ich halte es aber für unklar, wie und durch wen die Teammitglieder ermittelt werden, die das Team verlassen müssen.

Low Performer und Störenfriede
Als eine der schwierigeren Aufgaben im Projektmanagement empfinde ich den Umgang mit Teammitgliedern, die nicht das benötigte Leistungsniveau zeigen oder massiv und anhaltend Unruhe in die Gruppe bringen. Eine Stärke von Scrum kann bei der Selbstregulierung innerhalb der Gruppe liegen. Diese setzt aber entsprechende soziale Kompetenzen und ein gutes Standing bei den anderen Teammitgliedern voraus. Es ist möglich, dass das alleine die Situation nicht rettet. Dann ist der Scrum Master gefordert, solche Dinge zu erkennen, anzusprechen und auf eine Lösung zu drängen. Ultima Ratio bleibt in solchen Situationen, das entsprechende Teammitglied aus dem Team zu entfernen, wobei unklar ist, wer diese (harte und recht endgültige) Entscheidung fällen darf.

Fazit
Auch in diesem Bereich teilen sich die Aufgaben auf die neuen Rollen auf. Gerade für harte Entscheidungen, aber auch in der Startphase von Projekten kann der “klassische Projektleiter” trotz allem vermisst werden.

Eindrücke vom meettheexperts@codecentric, 18. Juni 2010

[Show as slideshow]

Bewertungen der Teilnehmer

Ich freue mich, dass die Teilnehmer die vier Vorträge (Details dazu weiter unten im Text) sehr gut aufgefasst haben. Insgesamt wurden die Sprecher und Inhalte durch die Bank positiv bewertet. Selbst die beiden englischen Vorträge waren für die allermeisten kein Problem, sobald man sich einmal “eingehört” hat.

Die allgemeinen Beurteilungen für den Tag waren wie gewohnt sehr positiv, ohne an dieser Stelle auf die Details eingehen zu wollen. Die Erwartungen mit den Experten in einen aktiven Dialog eintreten zu können und praxisrelevante Diskussionen führen zu können wurde offenbar voll erfüllt. Einzig das Ergebnis des Spiels “Deutschland : Serbien” bei der Fußballweltmeisterschaft ließ zu wünschen übrig. Auch der Open Space wurde wieder intensiv genutzt um eigene Themen mitbringen zu können, hier hat sich aber gezeigt, dass wir diesen noch besser vorbereiten können. Ich denke für das nächste meettheexperts@codecentric zum Thema Architektur werden wir den Teilnehmern schon vorab Infos zuschicken (am besten auf Papier), wie wir das Open Space organisieren werden, uns sie dazu ermuntern sich schon im Vorfeld ein Thema zu überlegen, welches Sie zur Diskussion stellen möchten.

Details zu den einzelnen Vorträgen

Aus technischen Gründen können wir die Vorträge momentan nur als Download von der Homepage und über Slideshare anbieten. Die Videos werden so schnell wie möglich nachgereicht (sobald wir wieder eine entsprechende Kamera haben, um das Material auf einen PC zu bekommen)

Keynote – von Ken Schwaber

Ken Schwaber, einer der Erfinder von Scrum und Mitbegründer der Scrum Alliance und seiner neuen Organisation scrum.org spricht über den aktuellen Zustand von Scrum. Ich habe mich riesig gefreut, dass er für den Tag zugesagt hatte! Wann hat man schon mal die Möglichkeit mit ihm Auge in Auge über Scrum diskutieren zu können? Während die Präsentation eher “rustikal” aussieht, war der Inhalt des Vortrags fesselnd. Ken diskutierte die Schwierigkeiten und teilweise auch Missverständnisse im Umgang mit Scrum; welchen Einfluß technische Schulden und ein unfertiges “Done” auf die Geschwindigkeit, das Return on Investment und sogar die Überlebenswahrscheinlichkeit des Unternehmens haben. Für mich das schönste Zitat ist, dass Scrum wie die eigene Schwiegermutter sei: Sie sagt einem nur andauernd, was man alles falsch macht, aber nie wie man die Sache besser machen soll!

Professional Scrum Developer – von Andreas Ebbert-Karroum

Andreas stellte fest, dass es an der Zeit ist, neben den erfolgreichen Trainings für die beiden Rollen “Product Owner” und “ScrumMaster”, auch ein Training für die Mitglieder in einem agilen Team zu starten. Hier ist codecentric Program Development Partner des Professional Scrum Developer Trainings, d.h. zusammen mit scrum.org konzipieren wir die Inhalte des 5-tägigen Trainings. Im Vortrag stellt Andreas die Elemente vor, die nach seiner Erfahrung notwendig sind, damit ein Team im Scrumkontext erfolgreich ein Softwareprodukt entwickeln kann.

Was ist TDD? – von Bernd Schiffer

TDD – ein alter Hut. Oder? Eigentlich ist Test Driven Development nichts neues mehr, trotzdem wird es oft immer noch nicht durchgeführt. Was ist TDD eigentlich genau, und lohnt sich der Einsatz? Der Frage geht Bernd in seinem Vortrag nach. Bernds wie immer sehr unterhaltsamer und mitreißender Vortragsstil hat auch diesmal die Zuhörer wieder begeistert. Sehr schön fand ich die Einlage, im Paar eine vermeindlich einfache Übung durchzuführen: Zählen, Klatschen, Hochhüpfen; und das im Wechsel und Wiederholend. Sehr witzig um zu verdeutlichen, dass einfache Regeln, wie der TDD-Zyklus, nicht sofort einfach umzusetzen sind. Von der Feststellung, dass “Go” ebenfalls nur einige einfache Regeln besitzt, musste Bernd sich nach einem kleinen Vortrag unseres “Profi Go-Spielers” Georg leider verabschieden

Exploratory Testing in Agile – von Elisabeth Hendrickson

Nach einem unerfreulichen Intermezzo der deutschen Nationalmannschaft, brachte Elisabeth wieder Schwung in die Runde. Nach einer kurzen Einführung warum auch exploratives Testen in einem agilen Umfeld notwendig ist, hat sie mit einem unserer Entwickler zusammen eine kurz vor der Fertigstellung stehende Webanwendung live getestet. An dieser Stelle nochmal einen herzlichen Dank sowohl an den Kunden, als auch das Team, das hierzu jeweils ein klares “OK” gegeben haben. Das war nicht selbstverständlich! Die Teilnehmer wurden jedenfalls mit einem sehr unterhaltsamen Vortrag belohnt, bei dem die Teilnehmer u.a. aktiv in das Testdesign mit einbezogen wurden. Die gefundenen Fehler wurde mittlerweile natürlich allesamt behoben.

Fazit

Abschließend kann ich eigentlich nur sagen, dass sich die ganze Arbeit der Organisation des Tages voll gelohnt hat. An dieser Stelle auch einmal meinen herzlichen Dank an alle Helfer hinter oder an der Bühne, die es wieder einmal möglich gemacht haben, dass wir alle einen sehr anregenden Tag verleben konnten, trotz der wie immer überraschend auftauchenden Probleme Danke, und bis zum nächsten meettheexperts@codecentric zum Thema Architektur, wie gewohnt in Solingen, am 17. September.

Beim Open Space kommen immer wieder super Diskussionen auf und es ist ein absolutes Highlight dieses Formats, dass die Experten beim OpenSpace noch wirklich greifbar sind

Das nächste meettheexperts@codecentric steht unmittelbar bevor. Wer sich noch nicht registriert hat, sollte dies schleunigst nachholen, denn die Liste der Experten ist mal wieder hervorragend besetzt. Teilnehmen am meettheexperts werden:

• Ken Schwaber, einer der Erfinder von Scrum. Letztes Jahr ist er aus der Scrum Alliance ausgetreten und hat eine neue Organisation gegründet: scrum.org. Gibt es eine bessere Möglichkeit aus seiner reichen Erfahrung schöpfen zu können?
• Bernd Schiffer, einer der agilen Experten Deutschlands. Was das Thema testgetriebene Entwicklung in Deutschland angeht ist Bernd eine der Charakterköpfe im deutschsprachigen Raum. Der Vortrag selbst wird sich allgemein um das Thema TDD drehen (warum, wofür und wie), wärend ich mir sicher bin, dass wir Bernd zu etwas live-coding in einem Coding-Kata während des Open Spaces motivieren können.
• Elisabeth Hendrickson, vom Testen besessen, wie sie selbst über sich sagt. Sie ist Experte in der fachtestgetriebenen Entwicklung und wird live eine der von codecentric kürzlich implementierten Anwendungen testen – und bestimmt auch einige Fehler finden. Wie man dabei strukturiert vorgeht anstatt wild “rumzuklicken” wird sie dabei gerne erläutert.
• Andreas Ebbert-Karroum, Professional Scrum Developer Trainer. codecentric ist Program Development Partner von scrum.org und entwickelt das Professional Scrum Development (PSD) Training für Java. PSD ist das Pendant zum Certified ScrumMaster und Certified Scrum Product Owner. Warum gab es bisher noch kein Training für die Teammitglieder? Andreas wird erläutern, warum dieses Versäumnis erst jetzt nachgeholt wird, und warum ein Team ein Training benötigt.

Das meettheexperts findet diesen Freitag statt, also am 18. Juni. Richtig, das ist der Tag des zweiten Deutschlandspiels, und wer will das schon nach der mitreißenden Leistung gestern verpassen? Deshalb werden wir etwas von der üblichen Agenda abweichen und statt der Mittagspause eine verspätete, dafür längere Pause machen und uns zusammen das Spiel ansehen! (Vuvuzelas sind höchstens als Android oder iPhone App erlaubt )

Wer im Großraum Düsseldorf ist und Freitag nicht gerade heiratet oder dem Livegang eines 5-jährigen Multimillionen-Projektes beiwohnt, hat eigentlich keinen Grund sich nicht anzumelden Deshalb => JETZT ANMELDEN

Dr. Ingo Schrewe von der incowia GmbH und ich haben einen Artikel darüber geschrieben, wie einem Agilität helfen kann, die Risiken einer EAM-Einführung zu reduzieren und die Ergebnisse zu optimieren. Der Artikel ist im Rahmen eines EAM-Onlinespecials von SIGS-DATACOM erschienen und kann unter der folgenden URL heruntergeladen werden: http://www.sigs.de/publications/os/2010/EAM/friedrichsen_schrewe_OS_EAM_10.pdf

Ingo Schrewe und ich haben vor, den Artikel um weitere Artikel zu erweitern, in denen wir praktische Empfehlungen, Tipps und Beispiele für ein agiles EAM geben … wann auch immer wir die Zeit dafür finden, die Artikel zu schreiben …

Die Fachbereiche *liebten* die Agilität! Sie waren superglücklich über die kurzen Feedback-Zyklen und dass sie jemand hatten, der bereit war, wirklich mit ihnen zu kommunizieren, anstatt sie bei jedem Problem oder Anforderung immer nur aufzufordern, ein weiteres formales Dokument zu schreiben. Sie liebten es, wenn sie sehen konnten, wie ihre Vision in kurzen Iterationen heranwuchs und sie die Möglichkeit hatten, ihre eigenen Ideen dabei nachzujustieren. Sie fanden es sogar klasse, wenn sie bemerkten, dass sie mit ihren ursprünglichen Ideen auf dem Holzpfad waren, da sie die Möglichkeit hatten, diese Fehler einfach zu korrigieren und so das finale Produkt massiv verbessern konnten. Sie waren schlicht und ergreifend glücklich und hätten sie die Wahl gehabt, hätten sie nie wieder ein nicht-agiles Projekt gemacht.

Das Management mochte Agilität auch recht gerne. Das Management der Fachseite mochte es, weil seine Fachbereiche es liebten und das IT-Management mochte es, weil sich das Management der Fachseite nicht mehr über zu späte Liefertermine, zu hohe Belastung für ihre Leute oder ähnliches beschwerte. Okay, es war nicht immer Liebe auf den ersten Blick beim IT-Management. Oftmals waren sie schon recht misstrauisch gegenüber dem ganzen agilen Kram, weil sie keine Ahnung hatten, was auf sie zukommen würde, wenn das ein richtig dicker Erfolg werden sollte. Manchmal wünschten sich diese Manager hinter vorgehaltener Hand, dass das Projekt scheitern würde, denn dann hätten sie den ganzen Fachbereichs-Leute gezeigt, dass dieser agile Kram auch nicht funktioniert und man deshalb bei dem altbekannten und etablierten Vorgehen bleiben kann.

Und dann waren da noch die Entwickler, diese Leute aus den IT-Abteilungen des Kunden, die nach all den Jahren überglücklich sein sollten, dass sie endlich agil arbeiten durften, nicht wahr? Überraschenderweise waren die meisten von ihnen überhaupt nicht glücklich! Sie liebten ihre Prozesse und Artefakte sehr und die meiste Zeit drängten sie auf “mehr Formalismus”. Sie fühlten sich sicher in der Welt, die sie sich über die Jahre geschaffen hatten. Wann immer in den vergangenen Jahren etwas schiefgegangen ist, haben sie ein weiteres Stück Formalismus hinzugefügt, einen weiteren Prozessschritt, ein weiteres Artefakt. Sie hatten sich ihre eigene, sehr komfortable Welt innerhalb der Grenzen ihrer Prozesse geschaffen. Alles hatte seinen Platz und seine Ordnung. Alles war in ihren Prozessen beschrieben und Dinge, die nicht in den Prozessen beschrieben waren, waren schlicht und ergreifend verboten. Und das Beste daran: Niemand musste wirklich Verantwortung für irgendeinen Fehler übernehmen. Solange man sich an die Prozesse gehalten hat, hat man alles richtig gemacht und wenn etwas schiefgegangen ist, musste es der Fehler von jemand anderen sein. Also, tue einfach brav, was immer der Prozess Dir vorschreibt und Du bist sicher! Uff, was für eine Erleichterung!

Man kann sich sicherlich vorstellen, dass Agilität mit seinem Fokus auf Ergebnissen anstatt Prozessen, mit eigenverantwortlichen Teams, die Verantwortung für das Ergebnis übernehmen, mit seinem Druck, mit Fachbereichsleuten zu sprechen, um Dinge zu klären anstatt einfach eine Spezifikation zurückzuweisen, dass dieses ganze seltsame agile Ding nicht wirklich das war, auf das diese Entwickler gewartet haben. Tatsächlich hat es ihnen richtig Angst gemacht! Sie fühlten sich verdammt unwohl damit. Sie wussten nicht, wie sie damit umgehen sollten und hatten immer dieses angsteinflößende Gefühl, dass sie schuld sein könnten, falls irgendetwas schief gehen würde. Nein, sie waren überhaupt nicht glücklich!

Okay, ich gebe zu, dass ich es ein wenig überspitzt dargestellt habe, um den Punkt herauszuarbeiten, aber: Das ist kein spezifisches Problem irgendeines unserer Kunden; das ist ein Phänomen, das man quer durch die ganze Branche beobachten kann. Wir hatten eine Menge Unterhaltungen und Diskussionen mit vielen anderen agilen Protagonisten, die uns unsere Beobachtungen bestätigt haben. Und es ist nicht so, dass die beschriebenen Entwickler Agilität nicht mögen, weil sie “böse” oder “ewiggestrig” oder was auch immer wären. Sie fühlen sich schlicht unsicher. Sie haben sich über Jahre hinweg ihre wohlorganisierte Komfortzone aufgebaut oder sind in diese Komfortzone hineingedrängt worden und sie haben einfach noch nicht gelernt, mit dieser Agilität umzugehen.

Und was ist die Moral von der Geschicht’? Ja, es bedarf einer Menge Change Management, um Agilität erfolgreich in einem Unternehmen zu etablieren, aber … *aber* ziemlich häufig sind es nicht die Fachbereiche, die wir auf die Agilität vorbereiten müssen; es sind die IT-Abteilungen, die wir auf die Agilität vorbereiten müssen. Seltsam, oder? …

PS: Ich rede nicht über *alle* Entwickler. Ich weiß, dass viele von Euch agil denken und es lieben, in einer agilen Weise zu arbeiten. Aber auf der anderen Seite gibt es immer noch diese große Masse an Entwicklern, die nicht agil arbeiten wollen oder zumindest nicht wissen, wie sie sich dahin entwickeln sollen und ich denke, es sind diese Leute, auf die wir unsere Veränderungsbemühungen konzentrieren müssen, nicht auf die Fachbereiche.

Andrew Hunt und David Thomas haben 2001 mit dem „The Pragmatic Programmer“ bereits ein Standard-Werk über den modernen Anwendungsentwickler geschrieben. Der Fokus liegt dabei aber auf Praktiken, Werkzeugen und Design-Paradigmen die dem Programmierer helfen besseren Code zu entwickeln.

Für agile Projekte reicht es aber aus meiner Sicht nicht aus nur ein „Pragmatic Programmer“ zu sein und in diesem Artikel möchte ich daher den Fokus auf den Entwickler in einem Scrum Team setzen. Ich sage hier explizit nicht „Programmierer“ sondern „Entwickler“, weil der Begriff Programmierer aus meiner Sicht zu sehr auf das codieren beschränkt ist und weniger die Tätigkeiten beschreibt, die zusätzlich notwendig sind, um guten Code zu erzeugen. (beispielsweise Design und Test)

Die Wurzeln von Scrum liegen laut Ken Schwaber (einem der Erfinder von Scrum) vor allem in einem Artikel der im Januar 1986 im Harvard Business Journal erschienen ist: „The New New Product Development Game“. Der Artikel beschäftigt sich damit, welche Kriterien eine erfolgreiche Produktentwicklung ausmachen und leitet daraus eine Kernthese ab:

„Stop playing the relay race – play rugby“.

Was frei Übersetzt bedeutet, dass man nicht mehr sequenziell („Wasserfall“), sondern ganzheitlich Produkte entwickeln soll.

Scrum hat die grundsätzliche Characteristiken für erfolgreiche Produkt Entwicklungen aufgegriffen und integriert. Beispielsweise Selbstorganisation der Teams, überlappende Entwicklungsphasen und unterschwellige Kontrolle. Diese Ansätze wurden um Ideen aus der iterativen, inkrementellen Entwicklung und der „Lean“ Welt erweitert. Die Scrum Alliance bietet heute Schulungen und Zertifizierungen zum Scrum Master und Product Owner an – nur was ist mit dem Entwickler? Liegt der Erfolg eines Projekts nicht vor allem im Team? Was bedeutet eigentlich Selbstorganisation, lauffähige Software alle 2-4 Wochen und überlappende Entwicklungsphasen für den Entwickler in einem Scrum Team?

Grundsätzlich glaube ich, dass die Arbeitsweise des Entwicklers in agilen Projekten im Vergleich zum Wasserfallmodell fundamental anders ist und deshalb auch andere, neue Fähigkeiten verlangt werden.

Beginnen wir mit einem der wichtigsten Dinge innerhalb agiler Projekte: Die Selbstorganisation des Teams – Selbstorganisation bedeutet, dass man als Entwickler nicht mehr von außen gesteuert wird, sondern sich mit den Teammitgliedern über die Zusammenarbeit abstimmt. Es bedeutet aber auch, dass man viel mehr Verantwortung übernimmt, mehr miteinander reden und diskutieren muss, Konflikte löst, sich selber organisiert, Aufwände schätzt und Commitments einhält. Dinge die in klassischen Projekten andere Rollen ausgeführt haben und aus meiner Erfahrung nicht gerade die Kernkompetenzen eines Programmierers sind. Es ist aber für den Erfolg von agilen Projekten fundamental erforderlich, dass sich Teams selber organisieren können – weshalb man auch die Entwickler mit entsprechenden Skills ausstatten sollte. Von vielen Organisationen weiß ich, dass Sozialkompetenztrainings vor allem den Führungskräften vorbehalten sind. Durch die Umkehr von „Command and Control“ müssen aus meiner Sicht vor allem auch die Teammitglieder, also auch die Entwickler geschult werden, im Team zu arbeiten. Dazu gehören beispielsweise Konfliktfähigkeit, Kommunikationsfähigkeit, Kompromissfähigkeit, Kritikfähigkeit, Toleranz und Verantwortung. Teammitglieder müssen die Stärken und Schwächen der Kollegen besser einschätzen zu können, was beispielsweise durch Methoden wie das Team Management System oder DISG erreicht werden kann. Wir haben nach der Einführung von Scrum bei codecentric festgestellt, dass wir neben den technischen und methodischen Skills auch die Sozialkompetenz schulen müssen, wenn wir erfolgreiche, agile Projekte durchführen wollen. Mit Hilfe externer Trainer haben wir ein spezielles Programm für uns ausgearbeitet, um die beschriebenen Fähigkeiten jedes Mitarbeiters nachhaltig zu verbessern.

Neben der Selbstorganisation erfordert aber auch die Überlappung der Entwicklungsphasen ganz neue Denkweisen bei uns Entwicklern. In den klassischen, sequentiellen Vorgehensmodellen wurden die Anforderungen im Detail ausgearbeitet, i.d.R. in ausführlichen Anforderungsdokumenten und detaillierten UML Diagrammen. Als Entwickler hat man diese Spezifikationen dann in lauffähigen Code umgesetzt und „Entwickler-getestet“ – für die eigentliche Qualitätssicherung waren andere Teams verantwortlich. Bei agilen Projekten verschwimmen die Grenzen zwischen Anforderungsmanagement, Analysten, Testern und Programmierern und als Entwickler muss man sich auch mit den „ungeliebten“ Randgebieten rumschlagen. D.h. aus meiner Sicht beispielsweise, dass man nicht nur mit Unit-Test auskommt, sondern in die Testgetriebene Entwicklung auch eher fachliche Integrations- und Akzeptanztests integrieren muss – i.d.R. werden diese dann gemeinsam mit Domänen Experten und erfahrenen Testern erstellt. Gerade wenn diese Tests für spätere Regressions-Phasen automatisiert werden (aus meiner Sicht ein Muss bei iterativ, inkrementeller Entwicklung), muss der Entwickler stärker involviert werden, um die speziellen Herausforderungen bei der Automatisierung, wie beispielsweise Testdaten-Setup, zu entwickeln. Geht man sogar soweit, dass man nicht nur bei Unit-Tests Test-Driven entwickelt, sondern auch bei den Integrations- und Akzeptanztest, sind entsprechendes Wissen um Vorgehen und Werkzeugen essentiell. Seien wir mal ehrlich: Man ist doch schon froh, wenn man Entwickler dazu bekommt TDD für Unit Tests anzuwenden oder überhaupt gute und ausreichende Unit Tests zu schreiben – das müssen wir durch entsprechendes Training/Coaching ändern.

Um diese Akzeptanztests zu erstellen und die wenig detaillierten User Stories umsetzen zu können, muss sich ein Entwickler viel intensiver mit der Fachlogik und den entsprechenden Personen im Team auseinandersetzen. Hierfür sind Kommunikationsfähigkeiten, aber auch entsprechende Praktiken, wie beispielsweise Domain Driven Design notwendig. In vielen Projekten sehe ich leider, dass sich Entwickler weniger mit der Domäne und mehr mit Frameworks wie Spring oder Hibernate beschäftigen; Generatoren, die aus Datenbankmodellen ein Objektmodell generieren sind eine nette technische Spielerei, hilfreich bei der Strukturierung und Kommunikation der Domäne sind sie allerdings  nicht. Das objekt-relationale Mapping wird dann zu einer relationalen Objektgenerierung und oftmals zu einer Wartbarkeits-Falle. Auch das ist aus meiner Sicht auf die zu starke Technologiefokussierung zurückzuführen, die man dann auch in der Struktur der Komponenten wiederfindet, die eher auf Basis von Maven-Vorgaben oder Technologie-Layern geschnitten werden, als auf Basis fachlicher Zusammenhänge und Service-Grenzen. Hier ist es meiner Meinung nach unbedingt notwendig Entwickler dahingehend zu schulen und zu coachen, dass Sie die Domaine als Kommunikationsinstrument mit den Fachabteilungen nutzen – so entstehen ganz „natürlich“ fachlich sinnvolle Strukturen und Domainen.

Um alle 2-4 Wochen fertige Software auszuliefern, darf man als Entwickler aber auch nicht die Technologien, Werkzeuge und agilen Entwicklungspraktiken vernachlässigen. Continuous Integration (z.B. Hudson, CruiseControl), automatisierte Build-Werkzeuge (z.B. Maven, Ant), Code Qualität Werkzeuge (z.B. Findbugs, PMD, Checkstyle), automatisierte Testwerkzeuge (z.B. JUnit, Robotframework, easyMock, DBUnit, JMeter), Codeverwaltung (z.B. git, Subversion), Bugtracker (z.B. Jira, Trac), Dokumentationswerkzeuge (Wiki, UML-Toos, Javadoc, etc.) sind dabei nur ein Auszug aus dem Portfolio eines modernen, agilen Entwicklers. Um dieses Portfolio optimal nutzen zu können und in eine „Definition of Done“ zu gießen, müssen die Teammitglieder auch im Umgang mit diesen Werkzeugen und Praktiken geschult werden. Dave Thomas, Co-Autor des „Pragmatischen Programmierers“, spricht sogar von „Code Katas“: Er zieht damit eine Parallele zum Karate, wo Katas bestimmte Trainingseinheiten sind, die immer und immer wieder wiederholt werden, um sie zu perfektionieren. Als Organisation müssen wir den Entwicklern also nicht nur entsprechendes Basis-Training geben, sondern auch Freiräume, um zu üben.

Neben ScrumMaster und Product Ownern müssen natürlich auch die Teammitglieder in Scrum geschult werden, denn die meisten Dinge in Scrum betreffen das Team und dieses muss über das Verständnis den Nutzen erkennen können. Beispielsweise, dass das Daily Scrum nicht für den Scrum Master gehalten wird (dieser muss ja nicht einmal mit anwesend sein, sondern nur dafür sorgen, dass es stattfindet), sondern um sich im Team auf den neusten Stand zu bringen und ggf. Probleme transparent zu machen. (Oft sieht man, dass der Scrum Master reihum die drei Fragen stellt und sich Antworten abholt…ein großes Missverständnis des Daily Scrums!) Oder dass das Burndown-Diagramm nicht zur Kontrolle des Teams durch Scrum Master oder Product Owner (oder sogar den Chef) gedacht ist, sondern als Hilfsmittel für das Team, die eigenen Commitments besser einhalten und überwachen zu können.

Am Ende bleibt noch festzustellen, dass insbesondere die Organisationen umdenken müssen. Das Spektrum des Agilen Entwicklers ist deutlich größer als die Summe der Technologien und erfordert viel Training und Übung – zudem einen hohen Erfahrungsaustausch im Team und innerhalb der Organisation, was schon bei „The New New Product Development Game“ festgestellt wurde: „Multilearning“ und „Organizational Transfer of Learning“ sind zwei der sechs wichtigen Erfolgsfaktoren in der Produktenwicklung! Agile Organisationen müssen also lernen, dass Training kein „Incentive“ ist, sondern ein absolutes Muss für alle Team Mitglieder eines agilen Projekts. Dazu gehören neben den Technologien und Werkzeugen auch Schulungen und Coachings um die Sozialkompetenz im Team nachhaltig zu stärken und agile Methoden, Praktiken und Paradigmen zu verstehen. Damit sich das aufgebaute Wissen der Entwickler auch außerhalb des Teams positiv wirken kann, müssen zudem Foren geschaffen werden, so dass sich die Entwickler im Unternehmen regelmäßig treffen und austauschen können. Diese Investition in die eigenen Mitarbeiter wird sich sehr schnell auszahlen!

Die Planung für dieses Jahr sind schon fast abgeschlossen und ich kann versprechen, dass wir wieder absolute Top Speaker verpflichten konnten – beispielsweise Dana Bredemeyer von Bredemeyer Consulting zum Thema Architekur und Elisabeth Hendrickson von Quality Tree zum Thema Agiles Testen. Details werden in diesem Monat bekannt gegeben und dann kann der “run” auf die 100 Plätze je Workshop beginnen.

Wer letztes Jahr nicht dabei war, kann sich die Speaker und Ihre Vorträge auch in der Meet The Experts Mediathek runterladen. Beim Workshop zum Thema Agilität haben wir die Vorträge mit der Videokamera mitgeschnitten und mit Adobe Presenter so bearbeitet, dass Video und Präsentation synchronisiert sind – so kann man sich einen guten Eindruck von der Qualität der Vorträge und Speaker machen:

• Hennig Wolf mit dem Thema “Agile Methoden im Überlick”
• Boris Gloger mit dem Thema “going LARGE by staying small”
• Simon Roberts mit dem Thema “Making Scrum Stick”
• Andreas Ebbert-Karroum mit dem Thema “Scrum Best Practices”

Über Feedback zu den Videos würde ich mich sehr freuen – es steckt viel Arbeit darin und mich würde interessieren, ob die Aufbereitung mit Adobe Presenter einen Mehrwert liefert. Wir überlegen in Zukunft alle Präsentationen in der Form zu veröffentichen.

Am Montag konnten wir schon als Speaker glänzen. Uwe Friedrichsen konnte das Publikum in seinem Vortrag von “Architektur und Agilität – Geht das und wenn ja wie?” von seinem Wissen überzeugen und wir haben am Montag einen Tag zusammen mit Alois Reitbauer von dynaTrace einen Workshop zum Thema “Java Enterprise Performance” gehalten. Zum Workshop werden auch noch in Kürze weitere Blog-Einträge von codecentric aber auch von dynaTrace folgen.

Als Silber-Sponsor sind wir nicht nur als Speaker präsent, sondern auch auf der Expo. Hier können sich  Interessierte von unseren Fähigkeiten überzeugen oder bestehende Kunden mit uns diskutieren. Dieses Jahr wollen wir vor allem von “Meet the Experts” erzählen und die Schulungen mit bekannten Trainern (z.B. Heinz Kabutz) bekannter machen.

Anbei ein paar Bilder von der W-JAX. Mehr folgt in Kürze….

Allein der Titel ist schon eine Ermahnung und einer der Gründe warum ich mir die Postkarte an den Monitor geklebt habe .

Kommen wir zu den Unterpunkten, welche diesmal nicht nur für Entwickler interessant sind:

• “Keep things tidy and organized”
  Es soll ja die chaotischen kreativen Entwickler geben… ehrlich gesagt glaube ich das viele einfach nur zu faul sind Ordnung zu halten…
  Ich kann mir schon vorstellen, das damals die Waffen immer griffbereit liegen mussten. Ein Glück, dass man sich heute nicht mehr am Arbeitsplatz körperlich verteidigen muss, zumindest müssen sollte…
• “Arrange enjoyable activities which streng then the group”
  Vorgesetzte, Scrum Master, Teamleiter, denkt daran, wer sprintet muß sich auch erholen, niemand kann immer nur schnell sein . Ich unterstütze diesen Punkt völlig!
  Wobei es mich schon interessiert was für die nordischen Männer als “enjoyable” galt…
• “Make sure everybody does useful work”
  Wieder ein Punkt der bei Agilität auch groß geschrieben wird. Durch Priorisierung bekommt der Kunde immer genau das, was für ihn am wertvollsten ist. Dieses impliziert, das jeder nützliche Arbeit leistet. Innerhalb des Teams sollte das Teamgefühl dafür sorgen, dass man nicht einfach nur seine Zeit versurft…
• “Consult all members of the group for advice”
  Ob die wohl früher auch “Stand-Up”-Meetings gemacht haben?
  In diesem letzten Punkt steckt für mich zum einen das tägliche Meeting, aber auch ein Stück weit Retrospektive. Einen guten Rat abzulehnen ist teuer, egal in welcher Hinsicht.

Ich bedanke mich bei allen, die sich die Zeit genommen haben mal etwas in die nordische Kultur abzutauchen . Ich kann nicht garantieren, dass die Gesetze wirklich in dieser Form existiert haben oder meine Interpretation korrekt ist, aber mir hat es echt Spaß gemacht meine ersten Blog-Einträge zu schreiben.

P.S. Dalsnibba (N62 02.935 E7 16.173), ein Blick auf das Dach der Welt.