War das gestern tatsächlich erst Tag 2 der Konferenz? Dann will ich mich beeilen meine Eindrücke festzuhalten, bevor der nächste Tag startet.
Keynote, mit Alistair Cockburn
Dr. Alistair Cockburn betrat nicht einfach die Bühne, nein er zog ein, begleitet von einem Dudelsackspieler, und eröffnete seine Rede mit einer Abwandlung von Shakespeares Julius Cäsesr. Im original heißt es dort (3. Aufzug, 2. Szene ) :
Begraben will ich Cäsarn, nicht ihn preisen.
Was Menschen Übles tun, das überlebt sie,
Das Gute wird mit ihnen oft begraben.So sei es auch mit Cäsarn! Der edle Brutus
Hat euch gesagt, daß er voll Herrschsucht war;
Und war er das, so war’s ein schwer Vergehen,
Und schwer hat Cäsar auch dafür gebüßt.[…]
Bei der Keynote wurde daraus:
I come to bury Agile, not to praise it;
The evil methods do lives after them,
The good is oft interred with their bones,
So let it be with Agile.The noble Waterfall hath told you Agile was ambitious:
If it were so, it was a grievous fault,
And grievously hath Agile answered it.[…]
Eine sehr interessante Eröffnung. Die Kernaussage der Präsentation war, dass „Agile“ wie ein geschmolzener Eisberg ist. Er sei ins Wasser der Softwareentwicklung gefallen, hat dort seine Spuren (Wellen) hinterlassen, sei jetzt aber selbstverständlicher Teil des ganzen. Desweiteren sei „Agile“ vor 15 Jahren als Idee für kleine Teams in einem Büro entstanden, und hat wenig mit der Größe (mehrere zehntausend Mitarbeiter) und Inhalt (lebensentscheidende Systeme) heutiger Anwendung zu tun. Wir bräuchten für das 21. Jahrhundert eine neue Art der Softwareentwicklung, die sich auf die folgenden Grundpfeiler stützt. Softwareentwicklung
- Ist ein Unternehmerisches Spiel: Softwareentwicklung sei ein kooperatives, endliches Spiel (jeweils bis zum nächsten Release am Iterationsende), mit einem ständigen Zielkonflikt zwischen der Lieferung der Software und dem Vorbereiten auf die nächste Runde. Man hätte drei Zugmöglichkeiten: Erfinden, Entscheiden oder Kommunizieren mit dem Problem, dass eine (Projekt-) Situation niemals einer anderen gleicht, also immer wieder neue Strategien entwickelt werden müssen.
- Ist ein Handwerk: Dieser Teil der Präsentation war eher mit Anekdoten gespickt, um zu verdeutlichen, wie wichtig es ist, sein Handwerk zu verstehen und dass man mehrere Entwicklungsstufen durchmacht, bis man sein Handwerk richtig beherrscht. Aus dem Japanischen sind die drei Stufen Shu (eine Technik lernen/kopieren), Ha (mehrere Techniken sammeln) und Ri (eigene Techniken entwickeln) entnommen.
Softwarefabrikation
Rückkopplung
Benutzt schlanke (lean) Prozesse: Man kann sich die Softwareentwicklung ganz nach dem Schema einer Fabrik vorstellen, wenn man „nicht validierte Entscheidungen“ als Stück betrachtet, dass durch die einzelnen Stufen der Produktionskette fließt. So kann man relativ einfach Engpässe identifizieren und den Flaschenhals entschärfen.
Während ich mit den drei Säulen durchaus einverstanden bin, finde ich die Ausgangsthese, dass Agilität jetzt erstens Mainstream ist und zweitens nicht dafür gedacht war, wohin es sich aktuell entwickelt, zumindest fraglich. Agilität mag zwar mittlerweile gedanklich hinreichend durchdrungen sein, weswegen es sich vielleicht weniger für neue Forschung und Veröffentlichungen eignet, deswegen ist es aber noch lange nicht überall Usus. Ob es initial ausschließlich für kleine Teams gedacht war vermag ich nicht zu beurteilen, mein Eindruck hingegen war bisher immer ein anderer. Auf Nachfrage aus dem Publikum hat Alistair betont, dass es ihm nicht darum geht die Agilität zu beerdigen. Vielmehr möchte er zum Ausdruck bringen, dass wir jetzt an einem Punkt angekommen sind, an dem wir neue Konzepte benötigen und uns neu orientieren müssen, um die nächsten Herausforderungen meistern zu können.
Die Motivation ist mir den ganzen Tag über unklar gewesen, bis abends während des „Open House“ bei ThoughtWorks (mehr dazu später) die „Agile Community of Practice “ des Project Management Instituts (PMI ) gegründet wurde. Dort wurde in die gleiche Kerbe geschlagen, dass das klassische Projekt Management Techniken zu bieten hat, die für große Projekte notwendig seien, gleichzeitig aber Agilität eine immer größere Rolle spielt. Da bisher das PMI und die Agile Alliance gedanklich eher auf verschiedenen Seiten wiederfanden, betrachte ich die Keynote als Versuch den Weg in die Zukunft zu ebnen, damit beide Organisationen zusammenfinden können.
Practically „Chrossing the Chasm“ from Project-level to Enterprise Adoption, mit Ahmed Sidky und Chris Sterling (pdf)
Crossing the Chasm
In der nächsten Session erhoffte ich einige Werkzeuge und Ideen mitzunehmen, wie Agilität in Unternehmen eingeführt werden kann. Die Präsentation war gut und aufschlussreich, allen die nicht teilnehmen konnten sei gesagt, dass sie den Inhalt relativ einfach nachlesen können. Alle Teilnehmer haben ein Exemplar von „Becoming Agile in an imperfect World “ von Greg Smith und Ahmed Sidky bekommen. Lest dort einfach das Kapitel 23.3 „Next Steps“ nach 🙂 Für mich habe ich mitgenommen, dass es bei der Einführung hilfreich sein kann, sich eine Karte zu erstellen, auf der man die umzusetzenden Maßnahmen einordnet. Dann kann man sich Stück für Stück von Maßnahmen, welche die Zusammenarbeit fördern, bis zu denen hocharbeiten, welche das ganze Unternehmen umfassen und auf Agilität ausrichten. Dabei ist es wichtig, dass man nicht erst ein Level komplett abgeschlossen haben muss, um sich dem nächsten zu widmen, sonderm man sich quasi „schräg“ von unten nach oben durcharbeitet.
XP: My Greatest Misses 2000 – 2009, mit J. B. Rainsberger
Augenscheinlich ging es in der Session darum zu betrachten, welche Lehren und Konsequenzen J. B. Rainsberger ganz persönlich aus seinen bisherigen Fehlschlägen gezogen hat. Im wesentlichen ging es darum, das Bewusstsein für Fehlkommunikation zu schärfen, da das den meisten Problemen zu Grunde liegt. Als hilfreiches Mittel wurde dazu das Satir Interaction Model vorgestellt. Am Anfang der Session hatte ich auf etwas interaktivere 90 Minuten gehofft, da wir aufgefordert wurden, uns alle einen Stuhl zu nehmen und in einer Ecke des Raumes einen Stuhlkreis zu bilden, letztendlich hat J. B. Rainsberger aber 90 Minuten am Stück erzählt. Trotzdem war die Session in der Hinsicht hilfreich, den Blick dafür zu schärfen, dass eine Kernthese des Agilen Manifests ja aussagt, dass Interaktionen und Individuen wichtiger sind als Prozesse und Werkzeuge, und trotzdem werden bei Trainings und Coaching zu dem Thema sehr häufig nur die notwendigen Prozesse und Werkzeuge vermittelt, und wenig wert auf die Verbesserung der Kommunikation und Interaktion gelegt.
User Stories for Agile Requirements, mit Mike Cohn
Hier gab es nicht viel Neues, aber es war interessant die Inhalte des Buches einmal von Mike Cohn persönlich erläutert zu bekommen, inkl. der Möglichkeit bei konkreten Fragen nachhaken zu können. Speziell die Relation von Epics, Themes und User Stories ist mir nun (hoffentlich) klarer geworden. Mein gedankliches Domänenmodell sieht jetzt so aus, dass es eigentlich nur „User Stories“ gibt. Ein Epic ist ein Label, dass eine User Story einfach „groß“ ist, ohne konkrete Aussagen darüber zu machen, was das genau heißt – davon abgesehen, dass ein Epic zu groß ist, um in einer Iteration umgesetzt werden zu können. Ein „Theme“ hingegen ist eine Ansammlung von „User Stories“ zu einem Thema, da ein Epic ebenfalls eine User Story ist, kann ein Thema also sowohl „normale“ User-Stories als auch Epics gruppieren.
Was zeichnet eine gute User Story aus? Sie sollte dem INVEST -Prinzip genügen: Independant, Negotiable, Valuable, Estimatable, Small und Testable sein. Am Schluß wurden User Stories noch gegen Use-Cases und IEEE Requirements („A system shall …“) abgegrenzt (wobei die User Stories natürlich sehr viel besser weggekommen sind).
ThoughtWorks Open House
Abends hatte ThoughtWorks zum Open House geladen. An dieser Stelle nochmal vielen Dank für die Möglichkeit und den tollen Empfang. Bei Essen und Getränken ergaben sich an den vorbereiteten Themenecken viele gute Diskussionen. Unter anderem war der älteste Continuous Integration Server der Welt zu sehen, behauptete jedenfalls Martin Fowler in der Eröffnungsrede. Witzig waren auch die Devil Duckies, „Rubberducking“ ist eine Technik des Pairprogrammings, wenn man gerade keinen zum „pairen“ hat, dann erzählt man eben alles seiner Quitscheente. Schon Ernie wusste damals, was gut ist.
Fish Bowl
User Experience Game
Discussions
Oldest CI Server
Birthday Cakes for the oldest CruiseControl
Devil Rubber Ducks
PMI and Agile
War dieser Beitrag hilfreich?
Weitere Beiträge
von Andreas Ebbert-Karroum
18.11.2020 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Andreas Ebbert-Karroum
Agile Principal Consultant
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.