Extreme Programming: 12 Praktiken für bessere Software

Chaos im Code, warten auf Feedback, immer mehr Bugs und Überstunden? Extreme Programming (XP) kann die Lösung sein.

XP ist ein agiles Framework, um eine hochqualitative Software effizient zu entwickeln. Anders als in Scrum gibt XP nicht nur einen Prozessrahmen vor, sondern auch 12 konkrete Praktiken, wie du das agile Mindset in der Praxis umsetzen kannst.

Diese Ansätze helfen dir dabei, die Qualität deines Codes und deiner Software zu erhöhen. In unserer Reihe Do better Scrum haben wir bereits festgestellt, dass sich Scrum so einiges von XP abschauen darf.

Was die 12 XP-Praktiken sind und warum du die ein oder andere Methode ausprobieren solltest, erfährst du hier.

Die Praktiken sind in drei Kategorien unterteilt, die grafisch in der Abbildung als Kreise sichtbar sind: 

1. Äußere Kreis: Business-bezogene Praktiken, regeln die Einbindung der Stakeholder und des Managements in den Prozess
2. Mittlerer Kreis: Team-bezogene Praktiken, betreffen die Kommunikation im Team und das Selbstmanagement
3. Innerer Kreis: Technische Praktiken, die die Qualität des Codes sicherstellen

Whole Team bedeutet, dass im Extreme Programming unterschiedliche Menschen gemeinsam an der Entwicklung einer Software arbeiten. Dabei ist die Zusammenarbeit ein essenzieller Faktor des Erfolgs. 

Die Teamarbeit beruht auf den Werten des Extreme Programmings: Einfachheit, Kommunikation, Respekt, Mut und Feedback. Das Team besteht aus Entwickler:innen, Kund:innen, Stakeholdern und Managern.

Das sind die Vorteile:

• Unterschiedliche Perspektiven: Alle im Team bringen ihre individuelle Perspektive ein. So lassen sich die Problemstellungen von unterschiedlichen Seiten beleuchten. Es werden (fast) alle Faktoren berücksichtigt und damit der maximale Nutzen erreicht.
• Effiziente Zusammenarbeit: Wenn alle Teammitglieder sich an den Werten orientieren, tragen sie zu einer effizienten Zusammenarbeit bei. Im Team herrscht eine positive Arbeitsatmosphäre, in der alle ihr Potenziale entfalten können.

So funktioniert es in der Praxis:

Eine offene und transparente Kommunikation ist die Basis. Alle im Team respektieren und engagieren sich, hören zu und binden die anderen in das Projekt ein. 

In Meetings kommen die Teammitglieder zusammen und tauschen sich aus. Stakeholder und Kund:innen können den Developern ihr Feedback geben.

Die Entwickler:innen wiederum ordnen die Anforderungen in den technischen Kontext ein. Gemeinsam entwickelt das Team eine Software, die nicht nur der technischen Exzellenz entspricht, sondern auch die Nutzerbedürfnisse optimal abdeckt.

Das Planning Game lässt sich mit dem Sprint Planning in Scrum vergleichen. Das Meeting findet in der Regel vor jedem Sprint statt. Allerdings lässt der Termin sich auch je nach Bedarf planen und individuell gestalten. 

Alle Stakeholder und das gesamte Developer Team nehmen teil. Die Agenda besteht aus zwei Teilen, dem Release Planning und dem Iteration Planning.

Die Vorteile sind:

• Klare Priorisierung: Im Meeting werden die Features nach ihrer Relevanz sortiert. Das Team gestaltet die Software so, dass sie immer den meisten Mehrwert bietet.
• Effiziente Planung: Die Developer tauschen sich zur Umsetzung aus, teilen Aufgaben ein und planen den Sprint vorab, was die Effizienz während des Sprints steigert.

Wie das Meeting abläuft:

Sowohl das Release Planning als auch das Iteration Planning bestehen aus drei Phasen: Exploration, Commitment und Steering. Im Release Planning bestimmt das gesamte Team, was genau für den nächsten Sprint geplant ist. Im Iteration Planning besprechen die Developer die Umsetzung.

1. Release Planning:

• Exploration: User Stories werden neu entwickelt und genauer spezifiziert.
• Commitment: Das Team priorisiert die User Stories und bestimmt, was sie im nächsten Sprint umsetzen.
• Steering: Der Plan wird aufgrund neuer Erkenntnisse ggf. adaptiert, neue Anforderungen ergänzt und finalisiert.

2. Iteration Planning:

• Exploration: Die Developer übersetzen die User Stories in Arbeitsschritten und schätzen deren Aufwände.
• Commitment: Die einzelnen Aufgaben werden unter den Teammitgliedern aufgeteilt.
• Steering: Die finalen Aufgabenbeschreibungen werden noch einmal mit den ursprünglichen User Stories verglichen, damit alle Anforderungen Berücksichtigung finden. 

Die Iterationen hält das Team möglichst kurz. In der Regel sind diese noch kürzer als in Scrum. Der Umfang ist begrenzt und auf wenige Änderungen fokussiert. So erhält das Team noch schnelleres und detaillierteres Feedback. Im besten Fall kann das Team ein wöchentliches oder sogar tägliches Review vornehmen. Manche Teams releasen sogar jede Stunde. Sie stellen damit kontinuierlich neue Versionen bereit (=Continous Delivery).

Die Vorteile sind:

• Kürzere Feedbackzyklen: Das konstante Feedback ermöglicht es die Software stetig zu optimieren. Da der Umfang auf wenige Funktionen begrenzt ist, kann das Team konzentrierter arbeiten. Der Kunde ist wiederum beim Testen fokussierter und gibt dem Team genaueres Feedback.  
• Weniger Fehlerquellen: Das Team geht kleinschrittiger vor und kann so rechtzeitig einlenken, wenn es in die falsche Richtung geht. Da die Änderungen detaillierter sind, sinkt auch die Wahrscheinlichkeit etwas falsch zu machen.
• Schnelles Time-to-market: Ein Nebeneffekt ist, dass dem Kunden in kurzen Abständen neue Releaeses der Software zur Verfügung stehen. Er oder sie darf dann entscheiden, ob die neue Version im Unternehmen ausgerollt wird oder nicht. 

Wie das funktioniert:

Das gesamte Team plant die Releases im Release Planning Meeting. Sie besprechen, welche Anforderungen die Developer im Sprint umsetzen. 

Dabei sollten sie den kurzen Zyklus beachten und den Umfang immer weiter einschränken, bis möglichst fokussierter Änderungen definiert sind. Das Team spezifiziert im Meeting die User Stories und legt die Prioritäten fest.

Die Umsetzung erfolgt z.B. innerhalb einer Woche, bis zur Veröffentlichung des neuen Releases. Es gibt auch Teams, die jeden Tag oder Stunde etwas ausliefern (= Continous Delivery).

Daraufhin erfolgt das Review, in dem der Kunde Feedback gibt. Die Abstände zwischen den Releases sollten nicht mehr als zwei Wochen betragen. 

Im Extreme Programming ist der Kunde direkt im Entwicklungsprozess integriert. Er testet die Funktionen und gibt den Developern Feedback. Die Rückmeldung des Kunden ist elementar, um die Software weiterzuentwickeln. Daher ist es hilfreich, wenn der Kunde immer erreichbar ist.

Das sind die Vorteile:

• Nutzerbedürfnisse abgedeckt: Wenn der Kunde konstant Feedback gibt, so werden die Nutzerbedürfnisse stetig berücksichtigt. Die Developer können die Software so gestalten, wie sie wirklich gebraucht wird. Der Nutzen der Software steigt.
• Maximale Transparenz: Die Feedbackschleifen im Extreme Programming sorgen für Transparenz. Der Kunde weiß immer, woran das Team arbeitet und bewertet das Ergebnis, sobald die Features fertig sind. Auf der anderen Seite bekommen die Developer ungefiltertes Feedback, um die Software zu optimieren.

Wie das genau funktioniert:

Im Planning Game kann der Kunde seine Anforderungen mittels User Stories einbringen. Damit bestimmt er mit den Developern, was im nächsten Sprint umgesetzt wird. 

Aus den User Stories entwickelt das Team Acceptance Tests, d.h. was ein Feature alles können muss.

Sobald die Features fertig entwickelt sind, führt der Kunde die Tests durch. Er bewertet deren Erfolg und gibt den Developern eine Rückmeldung. 

Wie sich die Acceptance Tests gestalten ist abhängig von den User Stories und wird immer wieder neu definiert.

Das Collective Ownership-Prinzip besagt, dass das gesamte Team auch für den gesamten Code verantwortlich ist. Alle im Team kennen die Funktionalität und die Logik des Codes, sodass alle auch an den unterschiedlichen Stellen im Code arbeiten und Änderungen vornehmen können. 

Fallen einem Developer Fehler auf, ist es seine Pflicht, diesen auszumerzen. Entweder selbst oder durch eines der Teammitglieder. Das Gleiche gilt auch für Verbesserungsvorschläge.

Warum wir darauf schwören:

• Bessere Zusammenarbeit: Es gibt keine Wissensinseln, sondern die Entwickler:innen tauschen sich untereinander aus. Dies erleichtert die Zusammenarbeit, gestaltet sie flexibler und stärkt auch das Gemeinschaftsgefühl. Das Ergebnis ist die Teamarbeit, nicht die Leistung eines Einzelnen.
• Proaktive Problemlösung: Fehler werden nicht einfach mehr hingenommen, sondern wirklich beseitigt. Die Verantwortung wird nicht an andere abgegeben, sondern es wird sich proaktiv um eine Lösung bemüht.
• Kontinuierliche Qualitätssteigerung: Die Software wird kontinuierlich verbessert, indem Fehler ausgemerzt werden. Beim Code schreiben fallen immer wieder Stellen auf, die noch nicht ganz stimmig sind. Das macht den Code cleaner. 

Wie genau das funktioniert:

Wenn dir ein Fehler auffällt, solltest du erst mit dem Team Rücksprache halten, bevor du etwas veränderst. Du kannst die Gründe nennen und ihr könnt im Team darüber diskutieren, was die beste Lösung ist.

 Falls du den Fehler selbst zu verantworten hast und dir sicher bist, dass sich die Anpassungen nicht anderweitig auswirken, kannst du die Korrektur auch eigenhändig vornehmen.

 Ansonsten stimmt ihr euch ab, damit eine Person aus dem Team den Code anpasst.

Alle im Team sind gleichberechtigt. Kommunikation und Transparenz sind das A und O. Jedes Teammitglied sollte jederzeit über den Stand des Codes Bescheid wissen. 
 

Sustainable Pace bedeutet auf Deutsch nachhaltige Geschwindigkeit. Das richtige Entwicklungstempo fordert, aber überfordert das Team nicht. Möglichst alle geplanten Features sollten in dem Release umgesetzt und das Release möglichst kurzgehalten werden.

Die Vorteile sind:

• Weniger Stress: Das Team ist weniger gestresst, macht keine Überstunden, ist motivierter und arbeitet langfristig produktiv. Außerdem steigt auch die Kreativität, um neue Lösungen zu finden.
• Konstante Qualität: Wenn der Umfang der Aufgaben zu hoch ist, kann die Qualität leiden. Es passieren häufiger Fehler oder Anforderungen werden nicht richtig umgesetzt. Bei dem optimalen Maß an Geschwindigkeit, bleibt die Qualität erhalten.
• Bessere Planbarkeit: Wenn die Geschwindigkeit moderat gewählt ist, bleibt sie in der Regel konstant. Das Team kann besser abschätzen, wie viel sie in einem Release schaffen. Außerdem gibt es weniger Altlasten, also technische Schulden, welche die Planungen über den Haufen werfen können. 

Wie das genau funktioniert:

Es ist ein Prozess, die richtige Geschwindigkeit zu finden. In den Planning Meetings sollte das Team beachten, dass sie nicht zu viele Aufgaben in die Iteration einplanen. Mit der Zeit können die Developer immer besser abschätzen, wie viel sie schaffen. 

Wenn das Team innerhalb des Sprints merkt, dass die geplante Umsetzung nicht realistisch ist, wird die Geschwindigkeit angepasst und der Umfang reduziert.

Wichtig: Niemand muss Überstunden machen, wenn fokussiertes Arbeiten möglich ist, kein Fokuswechsel durch bspw. mehrere Projekte stattfinden und ausreichend “Slack Time” besteht, sodass sich Mitarbeiter:innen mit neuen Technologien und Ideen beschäftigen können.

Alle Entwickler:innen sollten ihren geschriebenen Code so schnell und oft wie möglich in die aktuelle Version der Software integrieren. Am besten alle paar Stunden, mindestens jedoch einmal am Tag, sobald sie mit einem Abschnitt fertig sind und die Unit Tests positiv ausfallen.

Das sind die Vorteile:

• Fehler frühzeitig identifizieren: Integration findet möglichst früh statt. So werden Unstimmigkeiten und Abhängigkeiten frühzeitig erkannt. Fehler können sofort beseitigt werden, bevor Entwickler:innen an dem Code weiterschreiben.
• Code auf dem neusten Stand: Alle arbeiten immer mit der aktuellen Version des Codes. So wird vermieden, dass Entwickler:innen an einem veralteten Code schreiben.
• Reduktion der Integrationsaufwände: Die Kosten der Integration werden auf ein Minimum reduziert. Sodass möglichst wenig Aufwände auffallen, die einzelne Code- Snippets in den Code einzubauen.

Wie es funktioniert:

Um mehrmals täglich Änderungen zu integrieren, benötigt die Continuous Integration einige Vorbereitungen: Ein Code Repository, mit der sich Änderungen im Code nachvollziehen lassen, automatisierte Tests, eine zentrale Build-Pipeline, die automatisiert Änderungen integriert, baut und testet. Das klingt erst einmal viel.

Doch wenn die Infrastruktur aufgesetzt ist, so ist die Integration weitestgehend automatisiert, was wiederum viel Zeit spart.

Metaphor ist eine Strategie, bei der das Team eine einheitliche Sprache entwickelt, um die Kommunikation zwischen der Fachabteilung und den Entwickler:innen zu vereinfachen. Es geht darum, fachliche Aspekte besser greifen zu können.

Die fachlichen Begriffe finden dann auch im Code und der Software ihre Anwendung. Eine moderne Art der Metaphor ist das Domain-driven Design. Komplexe Zusammenhänge und Geschäftsvorgänge werden anhand der fachlichen Domäne modelliert.

Die Vorteile sind:

• Gemeinsames Verständnis: Das Team und der Kunde können sich einfacher austauschen. Sie sprechen die gleiche „Sprache“. Technische sowie fachliche Aspekte lassen sich einfacher erklären und aufgreifen. Die Entwickler:innen sprechen die Sprache der Nutzer:innen, statt technische Begriffe zu verwenden, die der Kunde womöglich nicht zuordnen kann.
• Reduzierte Komplexität: Komplexe und vielschichtige Vorgänge sind mithilfe der Modellierung einfacher zu erkennen. Zusammenhänge werden für alle sichtbar.

Wie das funktioniert:

Zunächst identifizieren XP-Teams zentrale fachliche Begriffe sowie Prozesse (auch genannt Domänen), welche Sie dann in der Software als Metaphern berücksichtigen. 

Auf diese Weise verwendet das Team die gleichen Begrifflichkeiten wie die Nutzer:innen. Die Metaphern abstrahieren komplexe technische Konzepten und werden bspw. auch im Code eingesetzt.

So sprechen Entwickler:innen, Kund:innen und andere Stakeholder eine gemeinsame Sprache. Das vereinfacht die Kommunikation und verhindert Missverständnisse.

Da sich Metaphern im Laufe der Zeit ändern, ist es wichtig die Sprache sowie die Software entsprechend anzupassen. Eine veraltete Metapher kann zu falschen Annahmen oder Missverständnissen führen.

Test-driven Development (Deutsch: testgetriebene Entwicklung) ist eine Vorgehensweise im Extreme Programming, bei der Entwickler:innen automatisierte Test für ein Feature schreiben, bevor sie es entwickeln. Auf diese Weise machen sich Entwickler:innen vorab Gedanken, wie ein Feature genutzt wird.

Gleichzeitig bauen sie ein Sicherheitsnetz, das Flüchtigkeits- oder Regressionsfehler auffängt. Die automatischen Tests unterstützen auch das Refactoring (dazu gleich mehr). Die sogenannten Unit Tests sind automatische Tests, die einzelne Features oder Stellen im Code testen.

Warum wir darauf schwören:

• Perspektivwechsel: Entwickler:innen nehmen die Perspektive der Nutzer:innen ein. Sie machen sich im Vorfeld Gedanken über unterschiedlichen Szenarien und identifizieren, was notwendig ist für die Funktionsfähigkeit des Codes. Dadurch steigt die Qualität des Codes.
• Weniger Bugs: Bereits bei der Entwicklung werden Fehlerquellen frühzeitig identifiziert. Dadurch werden Testphasen reduziert oder sogar unnötig, inbesondere Regressiontests. Es kommt zu weniger Bugs. Auch bei nachträglichen Änderungen besteht ein Sicherheitsnetz, dass die Funktionalität des Codes automatisch überprüft.
• Teil des Feedbackzyklus: Die automatisierten Tests ermöglichen ein Feedback im Sekundentakt. Du bekommst eine Rückmeldung, ob der Code die Anforderungen erfüllt. Du kannst sehr schnell erkennen, ob deine getroffenen Annahmen richtig sind oder nicht.
• Dokumentation: Zudem können anhand von den automatisierten Tests Rückschlüsse über die Intention der Entwickler:innen getroffen werden. Andere Entwickler:innen können den Code damit besser verstehen und einfacher anpassen.

Wie das genau funktioniert in Kürze:

1. Test-Code schreiben.
2. Produktions-Code schreiben.
3. Refactoring zu simplem Code: Tests erfolgreich, dann super, die Funktion ist fertig entwickelt! Tests nicht erfolgreich, dann Code so lange verändern, bis die Tests erfolgreich sind.

Wenn das Team die Software stetig weiterentwickelt, kann es schnell zu einem Chaos im Code kommen. Einzelne Code-Snippets werden mit der Zeit hinzugefügt. Bestehende werden immer wieder angepasst. Es entstehen neue Anforderungen, die entsprechend in der Software umgesetzt werden müssen.

Oder es ändern sich fachliche Begriffe, die auch im Code widerzuspiegeln sind (Domain Driven Design). Mit der Refactoring-Methode kannst du deinen Code auf die Änderungen vorbereiten und ihn verbessern, ohne dass du die Funktionalitäten veränderst. Dabei strukturiert du denn Code so um, dass er einfacher wird.

Das sind die Vorteile:

• Höhere Code-Qualität: Durch Refactoring wird die Qualität des Codes konstant gehalten oder sogar verbessert. Der Code bleibt so clean wie möglich. Dadurch wird auch die Software robuster.
• Änderungen einfacher möglich: Wenn der Code strukturiert ist, ist es einfacher, nachträglich Änderungen einzupflegen. Die Arbeit ist effizienter und birgt weniger Fehlerquellen.  
• Reduzierte Komplexität: Mit Refactoring lässt sich die Komplexität eines Codes reduzieren, die mit der Zeit ansteigt. Der Code ist besser lesbar. Erweiterungen können einfacher umgesetzt und Fehler schneller analysiert werden. 

Wie das genau funktioniert:

Wir empfehlen das Refactoring von Anfang an und kontinuierlich in der Entwicklung anzuwenden. Bei uns ist es Teil der alltäglichen Arbeit. Dabei gehen XP Entwickler:innen wie folgt vor:

1. Stellen im Code für das Refactoring identifizieren.
2. Refactoring ausführen: Code umstellen, Zeilen streichen, Code anpassen oder auf andere Weise die Struktur des Codes anpassen, sodass sie cleaner und einfacher ist.
3. Tests durchführen (Wichtig, damit die Funktionalität erhalten bleibt!): Tests erfolgreich, dann super! Gibt es noch weitere Stellen im Code zu verbessern? Tests nicht erfolgreich: Verändere den Code so lange, bis die Tests positiv sind.

Das Simple Design ist ein Ansatz, um den Code so clean wie möglich zu gestalten. Entwickler:innen sollten sich immer die Frage stellen, welcher der einfachste Weg ist, ein Feature zu entwickeln. Daraufhin sollten sie die simpelste Alternative wählen. Das Vorgehen kann dabei iterativ sein. Oft lässt es sich schwer von Anfang an bestimmen, was die einfachste Methode ist. Das Refactoring und der Test Driven Ansatz sind ebenfalls hilfreich, um einen simplen Code zu schreiben.  

Die Vorteile sind:

• Effizienteres Programmieren: Überlegen sich die Developer schon im Vorfeld, wie sie den Code möglichst einfach schreiben können, werden sie auch effizienter programmieren. Sie gehen weniger Umwege und sind schneller.
• Wartungsarbeiten: Wird der Code angepasst, die Software weiterentwickelt, so lässt sich der bestehende Code einfacher nachvollziehen. Die Entwickler:innen können Anpassungen leichter umsetzen.

Wie das genau funktioniert:

Bevor du den Code schreibst, identifiziere mögliche Wege und berücksichtige dabei die Einfachheit. Prüfe deinen Code, ob er den Regeln des Simple Designs folgt. Falls nicht, passe ihn so an, dass er den Kriterien entspricht. Das Simple Design wird wie folgt charakterisiert:

• Durchläuft alle Tests erfolgreich
• Drückt alle wichtigen fachlichen Ideen klar aus
• Enthält keinen duplizierten Code

Beim Pair Programming arbeiten Entwickler:innen zu zweit an der gleichen Aufgabe. Sie sitzen am selben PC, tauschen sich aus und schreiben gemeinsam den Code. Eine Abwandlung der Methode nennt sich auch Mob Programming, bei dem eine Gruppe an Developern von mehr als zwei Personen am gleichen Code werkelt.

Warum wir darauf schwören:

• Wissensverteilung: Die Entwickler:innen tauschen sich aus und können von den Erfahrungen anderer lernen. Vor allem Junior Developer profitieren, aber auch die Senioren werden immer wieder von neuen Ideen überrascht.
• Schnelles Feedback: Durch den direkten Austausch von Ideen, Annahmen und des Code Designs geben sich die Entwickler:innen kontinuierlich gegenseitig Feedback. Gemeinsame Code Reviews werden teilweise überflüssig.
• Kreative Lösungen: Es entstehen neue Lösungswege. Entwickler:innen bringen unterschiedliche Perspektive ein und vereinen ihre Fähigkeiten. Sie kommen schneller zu besseren Ergebnissen. Dadurch steigt die Qualität des Codes.
• Mehr Motivation: Die Motivation kann größer sein, wenn man gemeinsam an einer Aufgabe arbeitet. Es entsteht eine Teamdynamik, die sich positiv auf die gesamte Teamatmosphäre auswirkt. 

Wie das genau funktioniert:

Es gibt in der Regel zwei Rollen, die untereinander getauscht werden. Der Driver, auch Pilot genannt, schreibt den Code. Er übernimmt das technische Handwerk und fokussiert sich auf die Details im Code. 

Während der Navigator bzw. Observer sich der Problemstellung sowie der Lösung widmet. Er oder sie ordnet die Funktion in den Gesamtkontext ein und hat den Nutzen stets im Blick. Der Navigator schaut mit auf den Code. Er merkt an, wenn ihm etwas auffällt.

Diskussionen sind normal. Ja, sogar produktiv, wenn sie auf Augenhöhe stattfinden. Auf diese Weise setzen sich die Entwickler:innen intensiv mit der Aufgabe auseinander. Sie kommen zu neuen Lösungswegen und überdenken unterschiedliche Ansätze.

Allerdings: Pair Programming ergibt nicht immer Sinn. Leicht zu lösenden Aufgaben sind schneller alleine erledigt. Du kannst Aufgaben entsprechend der Komplexität einteilen.

Unserer Erfahrung nach ist es hilfreich, zumindest Aufgaben im Pairing zu beginnen. So kannst du mögliche Missverständnisse direkt aufdecken. 

Wenn du an einer Stelle nicht weiterkommst, hast du ein:e Ansprechparter:in, mit der du dich austauschen kannst. Das Code Review fällt im Anschluss kürzer aus. 

Die 12 Praktiken unterstützen dich dabei, eine hochqualitative Software zu entwickeln. Auch wenn du nicht mit Extreme Programming arbeitest, kannst du die Methoden für dich nutzen. Denn sie lassen sich alle gut mit anderen Frameworks wie Scrum kombinieren.

Die Tools kannst du individuell für dein Team und dein Projekt wählen. Schaut euch alles an, probiert euch aus und wendet das an, was euch den größten Mehrwert bietet.

Habt dabei immer das agile Mindset im Hinterkopf. Die Praktiken dienen vor allem dazu, die im XP definierten Werte in der Praxis umzusetzen. Wir nutzen einige der Praktiken für unsere Produktentwicklungen. Dadurch können unsere Teams eine spürbare Qualitätssteigerung erzielen.

Wenn du von unseren Erfahrungen lernen möchtest, schau gerne bei unserer lise Academy vorbei. Wir helfen dir gerne bei der Umsetzung und freuen uns auf dich!

Im vorherigen Beitrag unserer Reihe Do better Scrum sind wir näher auf die Methode des Pair Programmings eingegangen. 

Du erfährst, wie du das Tool für dich nutzen kannst. Und vor allem auch, warum Pair Programming keine Zeitverschwendung, sondern Gold wert ist.