5 Praktiken, die bei der agilen Software-Entwicklung helfen

Als technischer Scrum Master und technischer Agile Coach bin ich viel mit Teams unterwegs und begleite sie auf ihren Abenteuern. Das Abenteuer besteht aus regelmässigen Lieferungen von wertvoller Software für die effektive Produktfindung. Regelmässiges Liefern ist der Gedanke, der aus dem DevOps Movement kommt (Bauen wir schnell genug?) und die effektive Findung des richtigen Produkts, ist der wertgetriebene Gedanken (Bauen wir das Richtige?). Wobei richtiges Produkt bedeutet, dass das Produkt die Welt des Endbenutzers verbessert. Das heisst, der Benutzer kann schneller arbeiten, eine Aufgabe anders erledigen oder etwas machen, was vorher nicht möglich war (man könnte fast schon an Innovation denken).

Doch was ist beim agilen Arbeiten wirksam?

Was ich oft beobachten kann, ist, dass die Teams im Mini-Wasserfall-Modus arbeiten. Das heisst, in einem Scrum Sprint arbeiten sie in vier oder fünf Phasen.

Das sieht ungefähr so aus:

Das Problem dabei ist: Wir arbeiten so nur härter, aber nicht smarter.

Das heisst, wir haben nichts an unserer Arbeitsweise geändert, ausser dass wir vielleicht kleinere Häppchen in die Produktion bringen (was ja auch schon ein guter Fortschritt ist). Um den Vorteil von agiler Softwareentwicklung zu entfalten braucht es aber mehr. Es braucht ein anderes Vorgehen.

Fokussieren wir uns mal auf das «Testen». Das heisst, Teams reden von «Testern» (der Rolle) und «Testen» als Phase bzw. Aufgabe. Das sieht dann folgendermassen aus:

Hier entsteht ein Zusammenhang zum Wasserfall-Ansatz? Und damit entsteht eine Verschiebung, die nicht optimal ist.

Meiner Erfahrung nach passiert dann meistens:

• «Ahh.. Wir sind noch nicht ganz fertig mit entwickeln (Development).»
• «Könnt ihr noch mit Testen warten?»
• «Könnt ihr nicht einfach im nächsten Sprint testen, während wir weiterarbeiten?»
  → Spätestens hier sollte die Alarmglocke läuten.

Das sieht dann als Visualisierung meistens so aus:

Das heisst, die Zeit für das Testen wird zu kurz. Es wird zu wenig, erst später gemacht oder in grossen Batches (viel auf einmal) getestet und das führt wiederum zu Schuldzuweisungen, langen Test-Abenden, später Integration, zweimonatlichen Deployments (Bereitstellungen) – und zu allgemeiner Frustration.

Wie kommen wir von Wasserfall zu 1-Wochen-sprints?

Was in meiner Erfahrung gut funktioniert, ist der folgende Ablauf, vielleicht könnte man auch Progression im Team sagen):

1. Wir fokussieren uns auf 1-Piece-Flow

Das ist ein Gedanke aus der Lean-Philosophie, wo wir kleine Arbeit ganz fertig machen und uns dann erst die nächste Arbeit holen.

2.Wir bauen von Anfang an Qualität ein

Nur hohe Qualität lässt uns mit der Zeit schneller werden, und wir nutzen diesen Ansatz für die langfristige Entwicklung.

3. Wir automatisieren sehr viele Tests

… und können uns als Menschen auf die spannenden manuellen explorativen Tests fokussieren. Menschen sind schlechte Automaten. Maschinen können viel besser langweilige automatische Dinge abchecken.

4. Wir arbeiten testgetrieben

Ein roter Test aus der Aussensicht sagt uns, dass wir ein Feature einbauen oder umbauen müssen. Wir nutzen Tests als Indikator für: Da ist Arbeit zu tun.

5. Wir helfen das beste System zu bauen

… durch frühe Kommunikation mit Fragen und Fokus auf Qualität. Das Team hat jetzt mehr Zeit mit der Aussenwelt zu kommunizieren und dort Ideen, Hypothesen und Anforderungen zu challengen und besser zu modellieren und validieren. Die Aussenwelt besteht aus den «Stakeholdern»: Usern, Managern und andere Beteiligte.

Wenn man arbeitet, wie in Punkt 1 bis 5 dargestellt, dann sieht das typischerweise so aus:

Wie man dazu umdenken muss:

• Testen ist eine Aktivität.
• Testen findet die ganze Zeit statt.

Was man anders machen muss:

• Unsere automatisierten Tests treiben die Entwicklung.
• Unsere automatisierten Tests treiben die Architektur.
• Alles grüne Tests heisst: «Wir sind fertig»