Scrum Gathering Paris 2013 – Agiler Szenetreff am Eiffelturm

Wenn 400 Menschen aus 38 Ländern zusammenkommen, um ihre Leidenschaft für eine Arbeitsphilosophie zu teilen, dann muss es gut werden. Zwei Tage voller Workshops und Vorträge vergingen wie im Flug, die Abende in Paris profitierten vom Flair der Metropole.

Mein persönliches Highlight der Konferenz waren die Keynotes: Henrik Kniberg, der über Agilität im Großen bei Spotify berichtete. Eine Firma, die es durch ein geschicktes Skalierungsmodell geschafft hat, agil zu bleiben trotz massiven Wachstums. Keine leichte Aufgabe.

Dan Mezick folgte, der über seine inspirierenden Ansätze der Kulturveränderungen in verschiedenen Unternehmen berichtete. Sein Modell von agilen Transitionen präsentierte er unter der Kernfrage:

Wie schaffen wir es, dass Agilität langfristig bleibt?

An den Themen des Gatherings merkt man: Viele Firmen haben mittlerweile Erfahrung mit Scrum gesammelt – manche Firmen führen sogar Scrum zum zweiten Mal ein, weil sie die Agilität auf Ihrem Weg dann doch verloren oder die Einführung nur halbherzig begonnen haben. Die Fragestellung, wie Agilität dauerhaft in Firmen existieren kann, beschäftigt Firmen wie Community also intensiv.

Gespanntes Zuhören während einer KeynoteWichtige Eckpfeiler dafür sind das klare und dauerhafte Erleben der Vorteile agilen Arbeitens – auch auf der Ebene des mittleren und oberen Managements – und die kontinuierliche Verbesserung auf allen Ebenen des Unternehmens an die sich stetig verändernden Rahmenbedinungen.

Das Ziel der größten agilen Allianz bleibt spannend: Die Arbeitswelt zu transformieren (analog zum englischen Slogan: „Transforming the world of work.“).

Gut 90% der Mitarbeiter bei Spotify sind mit ihrem Arbeitsplatz sehr zufrieden. Welche deutsche Firma kann das von sich sagen?

Es gibt viel zu tun. Mit Agilität haben wir einen lohnenswerten Weg. Lasst uns gemeinsam das Morgen gestalten, in dem wir Arbeiten wollen.

Manchmal ist Scrum wertlos.

(c) Jared Tarbell, CC-BY-2.0

Viele Unternehmen beschäftigen sich mittlerweile mit Scrum. Neben durchaus erfolgreichen Transformationen von Teams und Abteilungen gibt es auch die Veränderungsinitativen, die auf ihrem Weg zu agilem Arbeiten stecken bleiben:

Mißverstandene Praktiken, fehlende Management-Unterstützung und fragwürdige Rollenverständnisse zeigen sich.

Doch was fehlt diesen Versuchen, Scrum zu etablieren eigentlich? Warum passen die Praktiken nicht oder fühlen sich inkongruent im Unternehmen an?

Bei der Suche nach der Antwort finden wir im ersten Buch von Ken Schwaber und Mike Beedle fünf Kernwerte von Scrum:

Mut, Offenheit, Respekt, Fokus, Commitment

Schauen wir uns die Scrum-Werte einmal etwas genauer an:

Mut ist die Fähigkeit, Herausforderungen trotz Risiken aktiv anzugehen, um Sie erfolgreich zu überwinden. Veränderungen benötigen diesen Mut: Unbekanntes und Neues will gelernt und gemeistert werden. Rollen verändern sich und der Status quo wird in Frage gestellt.

Offenheit ist das bereitwillige Aufnehmen und Teilen von Informationen, um Situationen einschätzen und richtig entscheiden zu können. Nur durch Offenheit entsteht die Transparenz, gute Entscheidungen zu treffen und gegenseitiges Verständnis für die Situation zu entwickeln.

Respekt ist Wertschätzung für Beitrag und Person aller Beteiligten, um konstruktiv zusammenzuarbeiten. Unterschiedliche Lebenswege, Meinungen und Perspektiven verdienen Anerkennung und wollen für Kreativität und Synergien genutzt werden.

Fokus ist die bewußte Einschränkung von Optionen, um gemeinsam effektiv voran zu kommen. Weniger ist mehr. Die Essenz umzusetzen in bester Qualität macht Kunden zufrieden und lässt uns Risiken steuern.

Commitment ist die Selbstverpflichtung zur Erledigung einer Aufgabe oder Mission, um Verlässlichkeit und Motivation zu erhöhen. Im Scrum Team genießen Angestellte eine hohe Freiheit und Selbstbestimmung. Damit wächst ihre Verantwortung für den Erfolg.

Die Einführung von Scrum bringt die Abteilung dazu, diese fünf Werte in ihrer Arbeitskultur zu schätzen: Scrum ist sozusagen ein Kulturwandler, ein Veränderungsagent im System, ein Katalysator für eine neue Form der Zusammenarbeit.

Die wichtigste Frage ist also, wieweit diese Zielkultur erwünscht ist und wie sie zu den weiteren Kulturelementen passen kann.

Einige Beispiele:

  • Wenn Harmonie (und somit Konfliktvermeidung) ein hoher Wert in der bestehenden Kultur ist, wie wird dann Mut wahrgenommen? Als Aggressor?
  • Wenn Erfolg der wichtigste Wert ist, darf Offenheit in der Kommunikation über Fehlschläge existieren?
  • Wenn Arbeit zugeteilt wird und top-down Deadlines ausgerufen werden, wie stark ist die gefühlte Selbstverpflichtung (also das Commitment) des Einzelnen?

Cargo Cult Scrum - (c) tattooblogger, CC-BY-2.0Schafft man es nicht, auf Grund der bestehenden Kultur die Werte von Scrum zu erlernen, sind diese Scrum-Implementierungen wert-los. Dem Vorgehen fehlt die Seele, die Praktiken wirken blutleer. Manche nennen dies einen Cargo-Cult: Ohne in der Tiefe zu verstehen, worum es geht, werden Praktiken falsch eingesetzt – und die erhoffte Veränderung bleibt aus.  Scrum löst sein Versprechen der besseren Arbeitswelt dann nicht ein – was zu verständlicher Frustration und Ablehnung der Methode führt.

Vor einer Scrum-Einführung lohnt es sich also, zu prüfen, ob die Zielkultur lohnenswert und erwünscht ist. Im Zweifelsfall erleben Sie in einem Scrum-Training oder während eines Pilotprojekts, wie sich Agilität anfühlt und welche Reibungspunkte es gibt.

Was ist Ihre Wunscharbeitskultur?

Was keine Handtasche mit sinkender Produktivität zu tun hat

Impediment Management in AktionMein Team lag in den letzten Zügen – das Sprintende war nur noch wenige Stunden entfernt, die letzte User Story noch nicht vom Product Owner abgenommen. Konzentrierte Stille im Teamraum mischte sich mit wachsender Anspannung. Während der internen Abnahme kam er dann, der Fehler in letzter Minute. Entwicklerin Natalie und unser Product Owner saßen vor dem PC und hatten den Testfall entdeckt, der den Prozess zum Abbruch bringt. Das Review Meeting mit eingeladenen Kunden und Anwendern in nur 3 Stunden brachte besorgte Gesichter. Wir wollen ihn schaffen, diesen Sprint!

Natalie war innerlich zerrißen. Bei der Fahrradtour vor einer Woche war eine Flasche Rotwein über die Handtasche einer Freundin gelaufen. Und diese Freundin hatte nun morgen Geburtstag. Eigentlich müsste Natalie jetzt in die Stadt und der Freundin die Longchamp-Tasche besorgen, um das wieder gutzumachen. Und eigentlich müsste sie auch an der Story weitermachen, um das Team jetzt nicht hängen zu lassen.

Unser Product Owner stellte schelmisch grinsend fest:

„Das ist doch ein Impediment, oder?“

Mit dem geliehenen Audi meines Product Owners und einem befreundeten Coach auf dem Beifahrersitz fuhren wir in die Innenstadt – zwei ScrumMaster gehen eine Handtasche besorgen – absurd?! Ist das noch die Rolle des ScrumMasters? Oder das Gegenteil davon? Eine Karrikatur der Produktivitätssteigerung? Geht das nicht zu weit? Der ScrumMaster als Kerl für alles?

Während ich darüber laut nachdachte, stellte mein Beifahrer die entscheidende Frage: „Macht es Dir Spaß?“ Ich lachte: „Total!“

Wir ScrumMaster sind für die Produktivitätssteigerung von Teams verantwortlich. Die Frage die ich mir stellte, gehört zu den klassischen Fragen dieser Rolle:

„Was kann ich jetzt gerade und langfristig tun, um mein Team optimal zu unterstützen?“

Manchmal ist es die Suche der richtiImpediment gelöstgen Ansprechpartner, das Herausheben der agilen Perspektive oder die Moderation von Teamworkshops.

Manchmal sind es schwerfällige Prozesse in der Organisation, gegenläufige Interessen verschiedener Gruppen oder mangelnde Kommunikation.

Und manchmal ist es der Einkauf einer Handtasche.

Das Team hat den Sprint übrigens erfolgreich abgeschlossen.

Scrum und IT-Kanban – Zwei Wege zur Agilität im Vergleich

(c) 2012, Muenchberger Service Jam, CC-BY-NDWährend Scrum schon seit etlichen Jahren die Veränderung in den IT-Abteilungen der Welt anführt, hat sich in den letzten Jahren noch ein Weg zu mehr Agilität entwickelt: IT-Kanban. Es lohnt sich daher, die Frage zu stellen, wo beide Wege Ähnlichkeiten besitzen und auch zu erkennen, wo Unterschiede sind, um entscheiden zu können, welche Vorgehensweise besser passen kann.

Scrum ist ein Framework für die Entwicklung und Wartung komplexer Produkte in Teamarbeit. IT-Kanban ist eine Change Management Methode, die eine schrittweise Transformation einer IT-Abteilung ermöglicht. Die Richtung dieser Veränderung kann hin zu mehr Agilität sein, muss es aber nicht. Das hängt von Ihren konkreten Zielen ab.

Scrum ist eine Revolution. Eine drastische Veränderung im Unternehmen, die auf diese Weise viele Probleme auf einmal beseitigen kann und alle anderen deutlich sichtbar macht.

IT-Kanban hingegen setzt auf Evolution in kleinen Schritten. Für manche Firmen ist dieser Weg angenehmer, dafür verpasst man möglicherweise das Potenzial, das in einer radikalen Veränderung steckt.

Ein wichtiges Konzept teilen beide Vorgehen: Sie etablieren Pull-Systeme also Umgebungen, in denen die Teams selbst entscheiden, wieviel Arbeit sie annehmen wollen. Und da es bei dieser Arbeit darum geht, mit möglichst wenig Aufwand den Kunden so früh wie möglich zufrieden zu stellen, folgende beide dem Denken der Lean Production (schlanke Produktion).

Das Sichtbarmachen von Wissensarbeit ist eine weitere Stärke, die beide Vorgehen nutzen: Durch Taskboards werden die in Arbeit befindlichen Aufgaben sichtbar und transparent für alle: Fortschritt wird greifbar.

(c) 2012, Muenchberg Service Jam, CC-BY-NDEin wichtiges Ziel ist eine optimierte Wertschöpfungskette. Das Mittel dazu die Etablierung einer Kaizen – Kultur durch Inspektion und Adaption.

Während Scrum dazu feste Iterationen als eine Art „Projekt-Herzschlag“ einsetzt, folgt IT-Kanban dem Fluß der Arbeit durch das System: Besprechungen werden durch situative Notwendigkeit einberufen.

Bei allen Unterschieden und Gemeinsamkeiten stellt sich damit die Frage, welcher Weg für Sie besser passt? Neben diesem Überblick ist die tiefere Beschäftigung mit beiden Vorgehensweisen wichtig, um die richtige Wahl für Ihre Situation zu treffen, denn der Transfer auf Ihren Kontext ist das Entscheidende.

Das klappt zum Beispiel mit einem Tagesworkshop, einer professionellen Kanban-Simulation oder auch im Selbststudium –  für den weiteren Einstieg finden Sie hier entsprechende Buchtipps.

Agile Spieleentwicklung an der SRH Hochschule Heidelberg

Scrum lernen mit simulierter ProduktentwicklungSeit Herbst 2010 kann man in Heidelberg den Studiengang „Virtuelle Realitäten“ an Deutschlands ältester privaten Präsenzhochschule studieren. Dieser Bachelor-Studiengang verbindet künstlerisch-kreative Aspekte mit klassischer Informatik. Also die Grundlage dafür, was ein Spieleentwickler heute können muss, um den nächsten AppStore-Download-Erfolg zu schaffen oder den Spielehit für den Heim-PC zu landen.

Auch die Spieleindustrie arbeitet teils schon seit Jahren agil, kurze Feedbackzyklen, Teamarbeit und Risikoreduktion sind auch hier wichtig, um erfolgreich zu sein. Folglich gehört es auf den Lehrplan.

Im Rahmen der Software Engineering Vorlesung der Hochschule SRH Heidelberg hatten die Studenten und Studentinnen die Möglichkeit, agile Methoden in Theorie und Praxis zu erleben. In einem Tagesworkshop hatten Sie die Aufgabe, eine Stadt zu bauen, die den Wünschen des Kunden entspricht. Hauptarbeitswerkzeug der simulierten Produktentwicklung: LEGO. Eine schöne Art, auf technologische Komplexität zu verzichten und dennoch viele Aspekte wie Qualität, Teamwork und Konstruktion zu erleben.

Die Vision des Kunden - gefertigt von drei Scrum TeamsIn mehreren Sprints bauten die Studenten in drei Teams Häuser, Hochschule, Bushaltestelle, Kindergarten und Krankenhaus. Erst langsam mit etlichen Mängeln aus Kundensicht, dann immer schneller und zuverlässiger genau das, was sich der Auftraggeber vorstellte.

Dementsprechend war auch das Feedback positiv: Das tatsächliche Erleben von Scrum wurde geschätzt wie auch der Spaß beim Erlernen.

Die Intensität der Praxisprojekte in diesem Studiengang ist übrigens besonders hoch, wie Studiengangleiter Prof. Dr. Daniel Görlich betonte. In diesem Sinne wünsche ich viel Erfolg bei der nächsten Spieleentwicklung – im studentischen Team oder beim kommenden Arbeitgeber!

Definition of Done verständlich erklärt

(c) Bernard Goldbach - Creative Commons

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.

Definition of Done (DOD)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.

Scrum, Kanban und Agile Leadership in der Metropolregion Rhein-Neckar lernen

Der ein oder andere hat es schon einmal selbst erlebt: Lernen und verstehen fällt einem besonders leicht, wenn man sich fokussieren kann und völlig rauskommt aus dem Tagesgeschäft. Nicht ohne Grund gibt es mittlerweile eine Vielzahl an Tagungshotels in Deutschland. Und oft ist schon die Anreise nicht nur eine „physikalische Entfernung“:

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.

Scrum Gathering Barcelona 2012 – Agile Methoden vermehrt im Nicht-IT-Umfeld

Was bewegt sich gerade in der agilen Welt, wo werden welche Erfahrungen mit Scrum gesammelt, was sind Trends und spannende Themen in dieser neuen Arbeitswelt, die wir Scrum Coaches mit unseren Kunden zusammen erschaffen?

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!

Qualitätssicherung in agilen Methoden

Scrum sagt, produziere potenziell auslieferbare Software in jedem Sprint, Kanban hat als Prinzip „Fokussiere Dich auf hohe Qualität„.

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.

Pair Programming – die kleinste Feedbackschleife in agilen Teams

Jeder Entwickler hat es schon einmal erlebt: Man kommt morgens zur Arbeit und ein Kollege hat sich krank gemeldet und wird vielleicht sogar längere Zeit nicht mehr ins Büro kommen.

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?