Und wo bleibt die Qualität?

„Wir sind das, was wir wiederholt tun. Vorzüglichkeit ist daher keine Handlung, sondern eine Gewohnheit.“ (Aristoteles)

„Nicht schon wieder!“ Product Owner Larry stürmt in den Teamraum. „Es ist schon wieder passiert! Heute haben wir wohl endgültig unsere letzte Glaubwürdigkeit beim Kunden verloren! Wie soll er jemals glauben, dass wir qualitativ hochwertige Software liefern können, wenn die Applikation beim Ausprobieren des neuen Sliders dreimal abstürzt? Wie ist sowas möglich?“

Tom, einer der Software Entwickler, zuckt mit den Schultern. „Woher sollen wir denn wissen, dass der Kunde einen höheren Wert als 50 eingeben möchte? Warum habt ihr das denn nicht getestet?“ wendet er sich mit vorwurfsvollem Blick an Maria, eine der Test Engineers.

"Aber sicher! Immer, wenn euer Code abstürzt, sind wir schuld. Warum könnt ihr nicht einfach anständigen Code schreiben? Ihr seid doch Software Entwickler, oder?“ Maria blickt wütend zu den drei Entwicklern im Team.

“Du hast die Story doch als Done abgenommen? Warum sind wir jetzt schuld?” fragt Ingrid, die Datenbank-Expertin des Teams, in Richtung Larry.

„Beruhigt euch!“ Petra, Scrum Master des Teams, kommt nun auch dazu. „Lasst uns alle mal einen Schritt zurücktreten und gemeinsam herausfinden, wo wir uns verbessern können! Alex, wolltest du nicht die Unit Tests für die Slider Klasse schreiben?“

„Ja, schon. Aber ich habe so lange gebraucht, um den letzten Feature Branch in unseren Master Branch zu mergen, dass sich das nicht mehr ausgegangen ist.“

„Sind Unit Tests nicht Teil unserer Definition of Done?“ will Petra wissen.

„Ich bin mir nicht sicher. Es ist schon eine Zeitlang her, seit ich die angeschaut habe. Sollte nicht Larry das überprüfen?“

Bevor Larry antworten kann, hebt Petra die Hand: „Einen Moment! Was ist mit dem Code Review? Wer hat den gemacht?“

Alle schauen wie gebannt auf ihre Bildschirme. Dann hebt Ingrid den Kopf: „Eigentlich hätte ich den machen sollen. Aber ich habe Toms Code noch nie verstanden, weil er immer so lange, komplizierte Funktionen schreibt. Und von seinen verschachtelten Schleifen bekomme ich Kopfschmerzen...“

Mit einem Seufzer wendet sich Petra an Georg, den zweiten Tester im Team: „Ich glaube, dass der letzte Absturz durch ein Feature verursacht wurde, das wir schon vor einigen Sprints geliefert haben. Ich bin mir ziemlich sicher, dass es dafür Unit Tests gab?“

„Einen Moment.“ Georg fängt an zu tippen und scrollt durch einige Seiten. „Lass mich kurz nachschauen... Ja, stimmt, wir haben Tests für die Datumsklasse. Aber es sieht so aus, als wäre die Hälfte von denen rot seitdem Ingrid die Klasse refactored hat. Ist dir das nicht aufgefallen, Ingrid?“.

„Ich bekomme andauernd Emails wegen fehlgeschlagener Tests. Einige Tests sind immer wieder mal rot und keiner weiß warum. Und ein paar müssen wir noch an die letzten Code-Änderungen anpassen. Hatten wir das nicht für den kommenden Sprint geplant?“...

Lassen wir Petra und ihr Team alleine weiter diskutieren. Wahrscheinlich hat jeder von uns schon mal so eine ähnliche Diskussion miterlebt oder war sogar selbst Teil davon. Einige haben sicher auch schon ein paar der Anti-Patterns des Teams erkannt, die zu schlechter Qualität führen.

Was läuft in diesem Team falsch? Verspricht Scrum uns nicht, hohe Qualität zu liefern?

Bewusstsein schaffen

“Continuous attention to technical excellence and good design.” lautet das neunte Agile Prinzip. Es sagt uns, dass Technical Excellence nicht etwas ist, das man auf einer Liste abhakt, sondern dass es das entsprechende Bewusstsein und unsere ständige Aufmerksamkeit benötigt. Das gesamte Scrum Team ist dafür verantwortlich, hohe Qualität zu liefern. Es ist nicht die Aufgabe von irgendeiner nachgelagerten Testabteilung oder der Qualitätssicherung.

Scrum gibt dem Team die Autorität zu entscheiden, wie eine User Story umgesetzt wird. Die Expertise und Erfahrung des Entwicklers wird anerkannt und man vertraut darauf, dass er oder sie die bestmögliche Lösung liefern wird. Dem Team sollte diese Verantwortung klar sein und es sollte sie annehmen und wertschätzen. Wir sollten das Team anspornen und unterstützen, dieser Anforderung gerecht zu werden und seine Handwerkskunst zu verbessern, wann immer es möglich ist.

Ein Scrum Team ist stolz sein, wenn der Kunde begeistert von einem neuen Feature ist, und es ist niedergeschlagen, wenn er nicht zufrieden ist. Daher ist es wichtig, dass die Teammitglieder so oft wie möglich die Gelegenheit haben, direktes Feedback von ihrem Kunden zu bekommen. Aus diesem Grund wird auch immer das Development Team die neuen User Stories im Review Meeting präsentieren. Es ist sein Produkt.

Mit einplanen

Hohe Qualität gibt es nicht gratis und sie passiert auch nicht einfach als “Nebenprodukt”. Man muss sie mit einplanen. Die Definiton of Done eines Teams sollte auch Vorgaben für die Qualität enthalten, die vom gelieferten Produkt erwartet wird. Beispiele dafür wären Unit Test Abdeckung, Source Code Metriken, alle Tests sind grün (klingt nach einem “No na” oder “eh klar”, aber aus eigener Erfahrung weiß ich, dass das einer der ersten Punkte ist, der gerne vernachlässigt oder vergessen wird), Code Reviews usw.

Beispielsweise kann man die notwendigen Unit Tests zu einer Story als eigene Tasks mit einplanen. Wenn diese auf dem Taskboard hängen, ist für alle Beteiligten klar, dass hier vom Team noch etwas zu tun ist.

Der Scrum Master wird mit dem Product Owner zusammenarbeiten, um ihm die Vorteile einer guten automatisierten Testabdeckung zu verdeutlichen, sodass er als PO nie mehr ohne leben möchte.

Das Management hat die Aufgabe, die Teams dabei zu unterstützen und zu motivieren, dass sie ihre technischen Skills kontinuierlich verbessern. Es sollten Möglichkeiten für Trainings, die Abhaltung von Coding Dojos und Informationsaustausch zwischen den Teams geschaffen werden. Dabei ist auch darauf zu achten, dass Mitarbeiter die Zeit zur Verfügung haben, um diese Optionen wahrzunehmen.

Sichtbar und transparent für alle

Guter Source Code glänzt mit Einfachheit und gutem Design. Die Verwendung von Metriken, die mit jedem Build automatisch generiert werden, hilft dabei, den aktuellen Zustand des Codes zu beurteilen. Tools wie Sonarqube erstellen übersichtliche Diagramme, die Aufschluss über die Einhaltung von Coding Guidelines, bewährte Source Code Metriken, die Testabdeckung und noch vieles mehr geben. Diese Berechnungen sollten in den Build Prozess integriert werden. Durch die Festlegung von minimalen Werten (z.B. für die Testabdeckung) wird ein Build als fehlgeschlagen markiert, wenn diese Werte unterschritten werden.

Aber man sollte sich nie darauf verlassen, dass diese Metriken für jeden einsehbar auf einer hübschen Webseite wohnen. Jemand muss das Team auch regelmäßig daran erinnern, dass diese Zahlen ihre Aufmerksamkeit brauchen und dass jeder, der in das Repository committed, auch für die gute Qualität des Codes verantwortlich ist. Manchmal reicht es schon, wenn der Scrum Master nach dem Daily Stand-up kurz nachfragt, wie es denn mit der Qualität aussieht. Nach einer Weile ist es für das Team selbstverständlich, auch diese Metriken regelmäßig als Bestandteil ihrer täglichen Arbeit zu überprüfen.

Die Definition of Done des Teams sollte als Gedankenstütze neben dem Taskboard hängen. Jedes Mal, wenn eine Story als fertig betrachtet wird, geht das Team noch mal alle Kriterien der Liste durch. Erst wenn alle erfüllt sind, ist die Story auch bereit für die Abnahme durch den PO.

Sich die Zeit nehmen

Man sollte nicht erwarten, dass die Umstellung der Gewohnheiten von heute auf morgen passiert. Kleine Schritte führen zum Ziel. Das Team muss dabei unterstützt werden, seine Verantwortung für die Qualität zu verstehen und anzunehmen. Nur dann kann es seine Art der Selbstorganisation entwickeln, in der hohe Qualität aus der täglichen Arbeit nicht mehr wegzudenken ist.

16 Feb

Und wo bleibt die Qualität? - Teil 2

Von Susanne Albinger

Es ist leicht, über Qualitätsbewusstsein und kollektive Verantwortung des Teams zu reden. Aber oft ist es eine Summe von kleinen Dingen und Praktiken, die ein Team in die Lage versetzen, konstant hohe Qualität zu liefern.

23 Jan

Dysfunktionen von Teams - 4

Von Alessandro Grimaldi

Scheu vor Verantwortung ist die vierte Funktionsstörung unter der ein Scrum Team leiden kann. Im Rahmen der Teamarbeit, bezieht sich die Verantwortlichkeit auf die Bereitschaft ...


Neueste Artikel

  • Herzlich willkommen!

    13.11. / Arjan de Jong

    Es war still im Büro der Giants. Lucas, der Teamleiter, hatte gerade zuvor verkündet, dass er eine Budgetfreigabe für ein neues Teammitglied bekommen hat. Das Team war euphorisch und alle freuten sich, weil sie sich schon lange Verstärkung gewünscht hatten. Als Francesco sich bei Lucas informiert hat, wie denn das Onboarding vor sich gehen sollte, lächelte dieser und antwortete: “Das ist Eure ...

  • Fokussiere deine Verbesserungen

    21.09. / Arjan de Jong

    Wer in einem agilen Team gearbeitet hat weiß, dass fast jedes Team durch externe Gründe irgendwann zum Stillstand gebracht wird. Existierende Probleme werden in agilen Vorgehensweisen schnell sichtbar, da diese Vorgehensweisen in kurze Iterationen geliefert werden ...

  • Dysfunktionen von Teams - 5

    17.08. / Alessandro Grimaldi

    Die ultimative Funktionsstörung eines Teams ist die Tendenz der Mitglieder, sich um etwas anderes, als die gemeinsamen Ziele des Teams, zu kümmern ...

  • Der Klebstoff, der alles zusammenhält

    24.04. / Susanne Albinger

    Man setze sechs Leute in einen Raum, versorge sie mit ausreichend Post-its, einem Taskboard und einem gemeinsamen Ziel und - voilá - fertig ist das Scrum Team! Hoch performant, kreativ und innovativ, und liefert alle zwei Wochen ein potentiell auslieferbares Produkt Inkrement. Klingt einfach. Aber…