Vor Kurzem hielt ich in einem Workshop ein Smartphone in die Luft und fragte einige Menschen, ob das ein gutes Telefon sei. Viele fanden es gut, manche okay und einer mochte es absolut nicht. Bei der Nachfrage nach Gründen stellten wir schnell fest, dass verschiedene Menschen verschiedene Qualitätsmerkmale betrachten und wichtig finden.

Das ist auch in einem Softwareentwicklungsteam nicht anders – bei der Frage, ob ein Stück entwickelte Software fertig ist, gibt es oft Uneinigkeit und Diskussionen. Woher weiß ich, dass ich fertig bin mit der Entwicklung? Was kann ich von meinen Kollegen erwarten, wenn sie ein Feature umsetzen? Was erwartet mein Product Owner?

Um diese Fragen in einem agilen Team zu beantworten und Klarheit zu schaffen, gibt es in der agilen Welt ein Artefakt mit dem Namen “Definition of Done”. Im Prinzip ist es soetwas ähnliches wie eine sehr spezifische Arbeitsvereinbarung oder selbst auferlegte Regeln, wie man Entwicklungsqualität definiert.

Eine Definition of Done (kurz: DOD) ist die Einigung eines agilen Teams darauf, was getan werden muss, damit ein Feature als fertig angesehen wird.

Man kann sich das als eine Art Kriterienkatalog oder Checkliste vorstellen, die man bei jedem Feature (sprich: User Story) durchgeht und auf Erfüllung überprüft:

• Habe ich Unit Tests entwickelt?
• Wurde die Dokumentation erweitert?
• Sind die Codekonventionen eingehalten?
• usw.

In einem Workshoptermin, den der Agile Coach bzw. ScrumMaster moderiert, wird diese Selbstverpflichtung des Teams als Einigung gemeinsam erarbeitet. In Zukunft ist sie die Basis für Klarheit bei der Frage, ob ein Feature fertig ist und hängt deswegen im Idealfall im Teamraum. Die Verantwortung für die Inhalte und auch die Einhaltung der Vereinbarung liegt ausschließlich beim Team. Ein wachsamer Agile Coach erinnert aber an die festgelegten Elemente zur passenden Gelegenheit.

Übrigens darf man im Laufe des Wachstums eines agilen Teams durchaus erwarten, dass die Definition of Done reift, somit mehr und umfangreichere Qualitätskriterien enthalten sind. Vielleicht ist es damit die erste Checkliste, die organisch wächst.

Doch dieses Wissen anderen Menschen zu vermitteln, ist nicht immer leicht. Was für einen selbst so logisch und beinahe selbstverständlich richtig erscheint, ist oft für andere  überhaupt nicht nachvollziehbar. Es gibt andere Sichtweisen, andere Meinungen, andere Ideen. “Das kann so bei uns nicht funktionieren” oder “es wäre besser, nochmals weitere Optionen zu untersuchen, bevor wir…” haben Sie vielleicht auch schon einmal gehört?

Doch wie schaffen Sie es, Ihre Idee zum Wohl Ihrer Abteilung und Ihres Unternehmens einzuführen? Wäre es nicht schön, wir könnten die Herausforderung der Veränderung leichter angehen?

Gute Neuigkeiten: Es geht leichter.

Die kostenfreie Simulation “FearlessJourney”, welche nun schon seit 2011 weltweit im Einsatz ist, gibt es nun auch auf Deutsch. Als Training für einen selbst oder (noch viel besser) in der Gruppe entwickeln Sie damit einen Satz von Strategien, wie Sie Ihre Idee am Besten einführen können.

Die im Spiel enthaltenen praxiserprobten 48 Strategien basieren auf dem in der agilen Welt bekannten Buch “Fearless Change”, welches ich – nicht erst nachdem ich Linda Rising persönlich kennenlernen durfte – als Ergänzung zu dem Spiel auch Ihnen gerne empfehle.

Wenn Sie auch Ihre Ideen auf fruchtbaren Boden aussähen wollen, können Sie FearlessJourney (in Deutsch und weiteren Sprachen) jetzt hier herunterladen.

Man kommt mehr und mehr weg von den Dingen, die einen täglich beschäftigen und auch der Stapel an nicht erledigten Unterlagen auf dem Schreibtisch oder Bürocontainer gerät in Vergessenheit.

Gerade in unserer Welt der nahezu permanenten Erreichbarkeit, sind Orte der Klarheit und Ruhe beinahe selten geworden.

Wer agile Methoden wie Scrum, Kanban und Management 3.0 lernen möchte, kann dies darum nun auch in den neuen Trainings- und Büroräumlichkeiten bei Heidelberg tun. Umgeben von herrlicher Natur fällt das Lernen besonders leicht in der renovierten ehemaligen Kornmühle der Stadt.

Am letzten Freitag konnten sich davon auch die Gäste der Einweihnungsfeier überzeugen und wünschten einen “guten Start in den neuen Räumen” – der vermutlich einzigen agilen Mühle in Deutschland.

Wenn Sie also in Zukunft mal wieder rauskommen wollen, um eine frische Perspektive auf Ihre Arbeit, Ihre Prozesse und Ihr Unternehmen zu werfen, haben Sie bei meinem Coaching und Trainings die Möglichkeit dazu.

Diesen Fragen konnte man im September in Barcelona auf dem jährlichen europäischen Scrum Gathering der größten Vereiningung von Anwendern dieser agilen Methode nachgehen.

Neben einer Keynote, die sich mit der Frage beschäftigte, wieso in Banken und Versicherungen häufig agile Methoden großen Herausforderungen begegnen gab es viele Sessions in drei verschiedenen Themenfeldern.

Meine Sessionauswahl richtete sich vor allem auf die Anwendungen agiler Methoden in Nicht-IT-Kontexten: Joe Justice lud uns ein, in den Konstruktionsprozess eines 2.5 Liter – Autos hineinzuschauen und es ist schon faszinierend zu sehen, wie ein Projekt aus Freiwilligen ein Fahrzeug aus einzelnen Modulen konstruiert, die in Minuten gegen andere ausgetauscht werden können. Hat ihr Werkstattleiter das schon einmal gesagt:

Dieselmotor oder Benzin? Nur einen Moment bitte…

Auch die Konstruktion von Fahrzeugsitzen des größten Automobilzulieferers Johnson Controls ist mittlerweile mit 300 Mitarbeitern in 53 Scrum-Teams organisiert. Wer hätte dies vor fünf Jahren kommen sehen?

Mein Fazit des Gatherings: Wo immer Wissensarbeit in Teams passiert, sind agile Methoden ein sehr guter Ansatz, um qualitativ und wirtschaftlich erfolgreich zu sein. Auch außerhalb der Softwarewelt. Probieren Sie es aus und profitieren Sie von der großen weltweiten Community!

Doch die Anwender moderner Anwendungen sind umfangreiche Features und Funktionen gewohnt, die eigentlich nicht in so kurzer Zeit wie einem Zwei- oder Vierwochenfenster umsetzbar sind.

Als Produktverantwortlicher (die Scrum’ler nennen sie Product Owner) könnte ich mir also die Frage stellen:

• Wie schneide ich eine Anforderung richtig, damit mein agiles Team optimal damit arbeiten kann?
• Wie zerlege ich große Features in kleinere, die unabhängig voneinander geplant und umgesetzt werden können?
• Wie komme ich weg von der “alles ist Prio 1″ Sichtweise hin zu differenzierteren Betrachtungen und damit mehr Handlungsoptionen im konkreten Projekt?

Es gibt ein gutes Hilfsmittel, um diese Fragen zu beantworten, welches ich gerne im Agile Coaching einsetze: Richard Lawrence hat ein tolles Flowchart “Userstories aufteilen” entwickelt, welches ich nun ins Deutsche übersetzt habe.

Die Datei enthält den grundlegenden Workflow, wie man Stories zerlegt und beinhaltet die beliebtesten Muster dazu in einer übersichtlichen Darstellung. Hintergrundinformationen zu den einzelnen Pattern bietet Lawrence dazu auch nochmal in seinem Blog an.

Sie können es kostenfrei hier herunterladen (PDF-Format), um damit in Zukunft leichter User Stories zu zerteilen und Ihre Teams optimal zu unterstützen. Viel Erfolg beim Einsatz!

• Wie schaffe ich es, zwischen der täglichen Arbeit genug Slack-Time vorzuhalten, um Verbesserungen und Innovationen umzusetzen?
• Wie erkenne ich, wo es gerade im Projekt klemmt und was ich jetzt tun sollte?
• Wieso ist weniger gleichzeitige Arbeit besser und wie sorge ich dafür, dass nur wenige Baustellen gleichzeitig existieren?
• Welchen Einfluss haben meine Managementvorgaben auf die Produktion?

Auf diese Fragen hat nicht nur das Framework Scrum sondern auch die flexible Change Management-Methode Kanban Antworten:

Einen ganzen Abend lang nutzten wir eine professionelle Kanban-Simulation in zwei Teams, welche gegeneinander als Mitbewerber antraten. Jedes von ihnen ein Softwareentwicklungsteam mit klarem Ziel: Möglichst viele Abonennten für einen Online-Dienst zu gewinnen und so wirtschaftlich besser abzuschneiden.

In mehreren Simulationsrunden konnte mit gemeinschaftlichen Aktionen die Art der Produktion gesteuert werden und die Grundprinzipien von Kanban vertieft werden.

Die mutigen Teams entschlossen sich auch, dass etwas komplizierte Flussüberwachungschart namens Cumulative Flow Diagramm zu verwenden, um möglichst viel Neues zu lernen.

Der Abend endete mit einer Schlußbesprechung, welche die wichtigsten Lernpunkte der Simulation nochmals aufgriff und für den ein oder anderen “Aha”-Moment sorgte.

Insgesamt ein sehr positives Teilnehmerfeedback mit Aussagen wie “macht Lust auf mehr” und “man lernt viel über Kanban” sprechen nicht nur für einen gelungenen Usergroup Abend sondern auch für gut investierte Zeit trotz Rheinstrand-Wetter.

Leicht erkennbar ist, dass agile Methoden Anforderungen an die zu produzierende Qualität einer Software treffen. Was bedeutet dies nun in der konkreten Anwendung im Unternehmen?

In der perfekten agilen Welt liefern wir einen kontinuierlichen Fluss von Funktionalitäten aus: Auf der Ebene einer jeden Story ist diese getestet auf ihre Qualität und im Kontext des Gesamtsystems validiert, im Extremfall nicht nur auf den Test- sondern auch auf den Produktivserver verteilt.

Um soetwas tun zu können, müssen wir in der Lage sein, mit geringem Aufwand zu prüfen, ob eine User Story funktioniert und die Erstellung der Story eine Auswirkung auf einen anderen Teil des Systems hatte. Schließlich wollen wir ja keine neuen Defekte hinzufügen, weil neue Funktionen hinzukommen. Mittlerweile gibt es ja eine ganze Hand voll Best Practices in diesem Bereich. Specification By Example, TDD, Integrations- und Unittests oder Konfigurationsmanagementtools sind einige von Ihnen.

Schaffen wir es, den Automatisationsgrad von Tests und Deployment so weit zu bringen, dass es im Sprint möglich ist, die Qualität zu sichern, die wir gerne hätten, haben wir Feedback dann zur Hand, wenn es am wichtigsten ist: Kurz nach der Produktion, wenn Entwickler noch wissen, wo der Defekt zu finden ist oder wie das Feature leicht zu modifizieren ist, damit es das tut, was der Kunde wirklich will. Denn wir wollen Fehler beheben, statt sie zu verwalten.

Abhängig von den Fähigkeiten im Team, den bisher verwendeten Tools, der Testbarkeit des Codes und der eigenen Disziplin ist die Erreichbarkeit solch einer Qualitätskontrolle für das eine Unternehmen eine überschaubare Strecke, für das andere ein Ultramarathon, der schnell als unmöglich schaffbar bezeichnet wird.

Ein befreundeter Agile Coach, der aus Leidenschaft extrem lange Strecken läuft, hat mir einmal erzählt, wie man eine 116km-Strecke angeht:

Viel Training, die Vorstellung des nächsten kleinen Abschnitts statt der ganzen Riesenstrecke im Kopf und: man sollte Lust darauf haben.

Wenn ihr Team sich gerne die Finger schmutzig macht, versuchen Sie es mit kleinen kontinuierlichen Schritten: Erweitern Sie die Definition of Done regelmäßig in der Form, dass mehr Aspekte auf Story- und Sprintebene fertiggestellt werden und weniger je Release. Das wird vielleicht zeitweilig anstrengend sein, aber Schritt für Schritt gelingt so auch der lange Lauf – wenn man darauf Lust hat.

Wer kümmert sich nun um die liegenbleibenden Aufgaben? Hat jemand das notwendige Wissen und kennt den Quelltext des Programms und die darin getroffenen Designentscheidungen gut genug, um schnell übernehmen zu können?

Um so schlechter das Wissen im Team verteilt ist, um so höher ist der etwas sarkastisch benannte “Truck-Faktor” – die Wahrscheinlichkeit, dass das Projekt scheitert, wenn ein Entwickler ausfällt.

Eine Lösung ist der regelmäßige Austausch über geschriebenen Quellcode. Während eine Version davon die bekannten Quellcodereviews darstellen, ist die aktivere Variante das so genannte Pair Programming (“Programmieren in Paaren”).

In einem permanenten Wechselspiel von zwei Entwicklern vor einem Computer entsteht so Quelltext, der während der Entstehung von vier Augen gesehen wird. Der gerade entwickelnde Kollege kommentiert während er Quelltext schreibt, was er tut, denkt also quasi laut.

Wenn der Programmierer, welcher gerade nicht die Tastatur hat, Fragen, Anmerkungen oder Ideen hat, teilt er sie dem Partner mit oder bittet kurzerhand um die Tastatur und “läßt Code sprechen”. So entsteht eine Feedbackschleife direkt dort, wo die Kunst bzw. das Handwerk stattfindet.

Dies spart nicht nur anderweitigen Kommunikationsaufwand, macht häufig mehr Spaß und hilft, Teams zusammenzubringen sondern steigert auch die Qualität, denn es rutschen weniger Bugs in den Produktivcode, wie die Grafik erläutert: Nur noch die Fehler, die beide Entwickler machen würden, kommen ungesehen davon.

Der zeitliche Aufwand steigt dabei, jedoch arbeiten Paare oft etwas schneller, sodass mit leicht höheren Produktionskosten gerechnet werden muss – dies ist jedoch häufig eine sinnvolle Investition in vielen Vorhaben, die eine längere Lebensspanne überdauern sollen, berücksichtigt man die oben genannten Vorteile. Vielleicht kennen Sie ja die Kosten von Fehlern, die an Ihre Kunden ausgeliefert worden sind? Entscheiden Sie selbst, ob diese Investition interessant sein kann!

Übrigens wird dann auch die Planung einer Iteration leichter, denn mehr Entwickler können nun immer mehr Aufgaben bearbeiten, da sie das benötigte Wissen gemeinsam haben.

Meine Empfehlung: Probieren Sie es aus und sprechen Sie über die Erfahrungen in einer Retrospektive.

…und wie wäre es eigentlich mit Pair Administration, Pair Designing und Pair Management?

Viele Jahre lang haben Führungsrkräfte versucht, das Verhalten durch möglichst detaillierte Vorgaben, Anweisungen und Regeln zu beeinflussen – ein Vorgehen, dass den Anleihen des Taylorismus geschuldet zu sein scheint. Das funktionierte mal mit mehr, mal mit weniger Erfolg.

Ein Trick in der Interaktion mit komplexen Systemen ist: Entscheidungen und Verantwortung werden dorthin gegeben, wo die Informationen präziser und kleiner sind. In der Regel ist das eine Delegation weiter “nach unten”. So werden die Entscheidungen besser und auch eher mitgetragen. Rahmenbedingungen helfen dabei, wichtige Entscheidungsaspekte zu berücksichtigen.

Komplexe Systeme haben emergente Eigenschaften: Das Verhalten des Systems kann nicht alleine durch das Verhalten der einzelnen Teile des Systems bestimmt werden. Ein Team ist mehr als die Summe seiner Mitglieder.

Als Konsequenz daraus verwendet man in agilen Vorgehensweisen die Intelligenz der Gruppe an allen wichtigen Stellen: Planung, Schätzungen, Reviews, Retrospektiven. Keine dieser Tätigkeiten kann von einer Person alleine in hoher Qualität geleistet werden, denn dafür sind zu wenige Informationen in der gedanklichen Abbildung jedes Einzelnen. Wer einmal bei einer Planning Poker Sitzung dabei war, kann dies dort leicht erkennen: Abweichende Schätzwerte sind immer in einem unterschiedlichen Wissenstand begründet. Hier wird aus den Einzelinformationen ein Gruppenmodell, dass die Komplexität einer Anforderung besser wiederspiegelt.

Aus dem selben Grund delegiert man – wie oben geschrieben – also auch möglichst viel Kontrolle an die Teams selbst: Sie haben das vollständigste Model zur Verfügung, um ihr eigenes System zu steuern. So steigt die Stabilität des Gesamtsystems Abteilung und Organisation.

Wir Ingenieure finden die Betrachtung, dass die Welt kausal funktioniert, irgendwie einleuchtend. Ich werfe Geld in den Fahrkartenautomaten und er druckt ein Ticket aus. Tut er das nicht, ist der Drucker vielleicht defekt oder das System muss neu gestartet werden. Aber nicht nur Ingenieure, die meisten Menschen sind der Meinung, dass es in der Regel einen Grund für ein Verhalten oder eine Situation gibt. Manchmal findet man ihn vielleicht einfach nicht so leicht. Oder?

Dieses Kausalität genannte Phänomen hat unsere Managementkultur stark geprägt. Führungskräfte versuchen in chaotischen Zuständen oder bei drohenden Fehlschlägen regelmäßig, die Kontrolle über die Situation zurückzugewinnen und die vermeintlich verantwortlichen Faktoren in die gewünschte Richtung zu beeinflußen. Im schlimmsten Fall gibt es die Suche nach einen Schuldigen.

Kausalität leistet der Wissenschaft einen unschätzbaren Dienst: Siedepunktberechnungen und Konstruktionspläne, vorhersagbare Flugbahnen von Raketen werden möglich. Und doch gibt es genügend Fragen, die wir nicht beantworten können: Wird unser Softwareprojekt wie geplant mit den definierten Funktionen fertig werden? Wie wird das Wetter in drei Wochen sein? Komme ich pünktlich zu meinem Termin am Freitag Abend durch die Münchener Innenstadt?

Wieso können wir diese Fragen nicht exakt beantworten? Was ist anders an ihnen?

Die Antwort ist die Komplexität. Damit ist nicht gemeint, wie man schnell denken könnte, dass es unüberschaubar viele Faktoren in einer Fragestellung gibt, sondern das unvorhersagbares Verhalten eines Systems. Dies zeigt uns zum Beispiel das Eulersche Dreikörperproblem von nur drei simplen Wassermolekülen: Die Zutaten sind simpel, das Systemverhalten komplex.

Solche Gegebenheiten blieben auch unseren Forschern nicht verborgen: Mittlerweile gibt es eine ganze Wissenschaft, die sich mit solchen Zusammenhängen beschäftigt, genannt die Disziplin der Komplexitätstheorie.

Wenn wir aufhören, kausales und lineares Denken auf komplexe Systeme wie Softwareprojekte und Teams anzuwenden und stattdessen auf die Komplexitätstheorie setzen, bedienen wir uns eines Modells, dass deutlich nützlicher ist und uns Antworten auf Fragen ermöglicht, die wir sonst nicht erhalten. Die Anwendung dieses Ansatzes auf die Führung von Scrum- und Kanban-Teams heißt “Agiles Management“.