5 Praktiken aus eXtreme Programming, die Dein Scrum-Team agiler machen

Nur 1% der Unternehmen, die agile Methoden nutzen, um Software zu entwickeln, setzen eXtreme Programming (XP) in Reinform ein. [1] Dennoch hat XP auch heute noch einen großen Einfluss auf die Art und Weise, wie wir Software entwickeln. Dabei kümmert sich XP um Prozesse, genau wie auch Scrum und Kanban. Doch wo Scrum und Kanban aufhören, geht eXtreme Programming noch einen Schritt weiter und sieht Codequalität als eine weitere Stütze der Agilität. Jeder Entwickler unter uns sollte einige der XP Praktiken kennen und einsetzen. Daher hier fünf Praktiken, die XP heute noch relevant machen.

1: Test Driven Development (TDD)

Du kennst das ungute Gefühl, das einen überkommt, wenn Du ungetesteten Code ändern sollst. Noch gemeiner sind unvollständige Tests, die einem das trügerische Gefühl der Sicherheit geben. Extreme Programming will Deinem Code mit TDD die Flexibilität geben, die Du und Dein Team für eine agile Entwicklung brauchen. Robert Martin, Mitgestalter des agilen Manifests und liebevoll Uncle Bob genannt, bezieht in seinem Buch „Clean Code“ eine binäre Sicht. Nach ihm ist jeder Code, der nicht testgetrieben entwickelt wurde bereit für den digitalen Papierkorb. Da Uncle Bob wahrscheinlich mehr Ahnung hat als Du und ich zusammen, sollten wir ihm einfach glauben.

2: Pair Programming

Schnell versammeln wir uns gemeinsam um einen PC, wenn wir einem komplizierten Bug einfach nicht auf die Spur kommen. Nach der erfolgreichen Lösung erzählen wir stolz im Stand-Up von unserem heroischen Pair Programming. „Pairing“ klingt zumindest cooler als “ich habe Hilfe gebraucht”. Doch Du solltest nicht nur „pairen“, wenn Du nicht mehr weiter weißt, sondern so oft es nur geht. Ja, Pairing macht Dich und Dein Team zunächst langsamer, die Codequalität steigt aber sofort und bleibt so flexibel. Weitere Benefits sind ein gemeinsames Verständnis und ein Wissenstransfer, der in dieser Granularität anders nicht möglich ist. Und willst Du mir sagen, dass Du Deine favorite Shortcuts nicht irgendwo abgeschaut hast?

3: Collective Code Ownership

Für viele von uns ist es ganz natürlich, gemeinsam für die Code-Base verantwortlich zu sein. Doch vielleicht arbeitest Du noch in einem Unternehmen, in dem jeder Entwickler nur für seinen Teil des Codes zuständig ist. Dies mag bei Dir vielleicht den Eindruck erwecken, dass Du so wichtiger für das Unternehmen bist, es macht Deinen Code aber schlechter und da Du nur wenig Neues lernen wirst, werden deine Skills bei einem neuen Arbeitgeber retro sein – und zwar nicht auf diese coole Nerd-Art und Weise. Und falls es sich Dein Unternehmen leisten kann über längere Zeit so ineffizient zu entwickeln, was machst Du dann mit dem schrecklichen Code von Kollege Herbert, wenn er von heute auf morgen das Handtuch wirft, weil es endlich mit dem Sechser im Lotto geklappt hat?

4: Customer Focus aka Whole Team

Die Idee der Story kommt aus XP und soll mit dem Namen dazu anregen, eine Konversation zu starten. Solche Konversationen sollen nicht nur in Deinem Team stattfinden, sondern vor allem mit dem Kunden. Nach XP sollte der Kunde deshalb Teil des Teams sein und somit jederzeit für eine Diskussion bereitstehen. Mit dieser Ansicht ist XP extremer als jede andere agile Vorgehensweise. Oft ist es unmöglich, seinen Kunden so in das Projekt einzubeziehen. Doch spielt der Fokus auf den Kunden auch in jeder anderen agilen Vorgehensweise eine zentrale Rolle, ein Beispiel hierfür ist die Rolle des Product Owners in Scrum. [2] Versuche also den Kunden oder Enduser mehr in Dein Team mit einzubinden – am besten Face-to-Face und so häufig es nur geht. Denn niemand entwickelt gerne Dinge, die keiner braucht. Ist es dennoch ein Hobby von Dir, welches Du unbedingt in der Arbeit ausleben willst, dann braucht Dich der Kunde irgendwann nicht mehr, weil Du mit ihm im Markt untergehen wirst.

5: Sustainable Pace

Überstunden zerstören nicht nur Deine geplanten Netflix-Abende, sondern machen laut XP in erster Linie Deinen Code schlechter. Doch wenn Du gefragt wirst, ob Du nicht ein paar Überstunden für das nächste Major-Release machen kannst, ist es oft schon zu spät. Kümmere Dich also früh darum, dass Dein Team sich um eine vernünftige Continiuous Integration Strategie kümmert und Feedback Zyklen mit dem Kunden nutzt. So könnt ihr die Fehler kurz vor einem weiteren Major-Release reduzieren, weil Du dieses Mal keinen Code gestresst oder schlaftrunken beim Überstundensammeln produzieren musst.

Das Fazit

Dieser Blog-Beitrag zeigt nicht das ganze Bild von XP. Doch ein Pattern von XP ist hoffentlich zu erkennen: Besserer Code ist flexibler/agiler Code. Und nicht umsonst sagt uns ein Prinzip aus dem agilen Manifest:

“Continuous attention to technical excellence and good design enhances agility.” [3]

Ein Prinzip, das man so explizit in anderen agilen Methoden wie z.B. Scrum vergebens sucht. Darum lohnt es sich nach diesem Blogbeitrag einen tieferen Blick in den Methoden Kasten von eXtreme Programming zu werfen und vielleicht in Zukunft mehr und mehr XP Praktiken in euren Scrum Prozess zu integrieren.