Nach einer fast schon philosophischen Eröffnung dieser Serie erläutert der zweite Blog den Einfluss von Prozessqualität auf die Verhältnisse der Teams. Wie versprochen werden anhand von konkreten Beispielen effektive Verbesserungspotentiale aufgezeigt, wie die Kosten der Qualitätssicherung reduziert werden können. Dafür verlassen wir die operative Umsetzung und kümmern uns um das Setup der Vorhaben. Wir schaffen mit sinnvollen und angemessenen Grundlagen optimale Verhältnisse mit und für effiziente Teams.
Natürlich müssen wir in den Teams die technischen Fähigkeiten unserer Rollen beherrschen, um effektive Resultate erzielen zu können. Schliesslich sind wir die Fachspezialisten und wissen die nötigen Methoden für unsere Aufgaben und Herausforderungen richtig anzuwenden. Wir wissen, mit welchen Aktivitäten relevante Artefakte erstellt werden und wer mit diesen Arbeitsprodukten arbeiten wird.
Business Analysten, Architekten, SW-Entwickler und Tester sind innerhalb des Teams voneinander abhängig und definieren die Zusammenarbeit mit der Team-Charta (sozialer Aspekt) und der Definition of Done (technischer Aspekt). Auf der technischen Ebene wird der Grundstein für die Prozessqualität gelegt, was aus eigener Erfahrung vernachlässigt wird und früher oder später zu Reibungen führt.
Auch wenn das agile Manifest «People over Product over Process» proklamiert heisst das nicht, dass der Prozess nicht wichtig ist. Schlanke und wirkungsvolle Konzepte machen nicht nur Sinn, sie vermeiden auch viel Aufwand während der Umsetzung in der Produktentwicklung. Das Aufsetzen der Prozesse sollte seriös im Sinne des gesamten Teams mit dem Team definiert und nicht nur als Punkt in der Definition of Done aufgeführt werden.
Es gibt keine Definition of Done, in welcher dieser Punkt fehlt. Was dafür fehlt ist die Definition von Dokumentation, dem Inhalt und der Form. Dank Werkzeugen wie Jira und Confluence ist die Sache ja erledigt und als Team müssen wir uns keine weiteren Gedanken darüber machen. Aber ist dem wirklich so?
Wie oft hatte ich das zweifelhafte Vergnügen, Produktdokumentation in einem Task (in Jira) zu finden, weil Spezifikationen direkt in der Beschreibung oder im Kommentar der User Story dokumentiert wurden. Im schlimmsten Fall besteht eine zusätzliche Wiki-Seite, wo eine widersprüchliche Information beschrieben ist. Die Frage nach der «richtigen Wahrheit» ist nicht nur ein Risikofaktor, dass etwas Falsches geliefert wird, sie kostet auch Zeit für die Klärung. Natürlich, in einem physischen Team kann die Antwort schnell gefunden werden, das skaliert aber leider nicht, auch wenn man mir immer wieder das Gegenteil beweisen will.
«Wir können ja über Tools kommunizieren, um solche Fragen zu klären», höre ich oft. Und genau mit diesem Argument verteilen wir relevante Informationen auf noch mehr Kanäle. Eine Nachvollziehbarkeit wird immer schwieriger und in nicht wenigen Fällen werden Entscheidungen in Teams- oder Slack-Kanälen getroffen, auf welchen nicht alle Personen vertreten sind. Das Finden von Informationen wird nicht nur schwieriger, es wird durch diesen Ansatz verhindert.
Diesen Punkt sehe ich schon seltener in der Definition of Ready, obwohl er das Fundament für Vertrauen in ein Team ist. Es ist wie in einem Restaurant: wenn wir direkten Einblick oder Zutritt in die Küche haben, können wir besser darüber entscheiden, ob wir dort essen möchten oder nicht. Wir haben auch bereits einen Anhaltspunkt, in welcher Zeit welche Qualität geliefert wird.
Vielleicht lehne ich mich jetzt ein bisschen weit aus dem Fenster, wenn ich behaupte, dass über 80% aller Teams lediglich das Burndown-Chart als messbaren Faktor definieren. Eventuell steht noch ein Quality-Dashboard zur Verfügung, aber viel mehr wird von Teams kaum gezeigt. Impediments werden sehr selten ausgewiesen und haben bei Demos oder Reviews kaum Platz. Der Grund liegt auf der Hand: Noch immer werden Teams an den gelieferten Stories und Features gemessen.
Fortschritt bedeutet nicht nur das, wieviel und in welcher Qualität wir liefern. Fortschritt bedeutet auch, dass wir Fehler machen oder gestellte Herausforderungen meistern müssen. Wir lernen in diesen Situationen und sind in der Lage, beim nächsten Mal effizienter zu sein. Fehler zu akzeptieren, trägt ebenfalls zum Vertrauen der Kunden bei. Informationen und Kennzahlen von ungeplanten Aktivitäten helfen zudem, dass das Team mit Erfahrungswerten betreffend Lösungsaufwand von Impediments besser planen können.
«Das bedeutet aber viel Dokumentation und das ist nicht agil», wird mir dann gesagt. Wirklich? Irgendwo werden Impediments aus Retros aufgeschrieben und regelmässig verfolgt. In praktisch jedem Team gibt es eine Wiki-Seite mit Herausforderungen, welche gelöst werden müssen. Darin werden Tabellen mit Tasks für Impediments erstellt, beschrieben, terminiert und einer Person zugewiesen. Dokumentiert wird also, einfach nicht im dafür konzipierten Werkzeug.
Wenn wir diesen Faden noch weiterspinnen, kommen wir zu einem Punkt aus dem letzten Blog-Beitrag: der Lebensqualität. Die tägliche Informationsüberflut verursacht Stress. Über die Hälfte (51%) von 1026 Schweizer Proband*innen (Alter: 15-79) einer Studie von Statista aus dem Jahr 2018 gab an, mit der Menge von Informationen im Alltag eher oder stark überfordert zu sein. Lediglich 11% empfinden gar keine Überforderung.
Slack, Teams, Outlook, Confluence und Jira bieten einfache Möglichkeiten, Informationen zu teilen und Aufträge zu erteilen (von den Social- und Businessmedia-Kanälen spreche ich gar nicht). Laut Harvard Business Review verursacht «Application Toggling» (dem Wechsel zwischen den Programmen) einen Aufwand von 9% unserer täglichen Arbeit. Das sind 5 Arbeitswochen pro Jahr.
Es gibt keine Studie über die Aufgaben, welche in dieser Flut untergehen. Aus meiner Erfahrung und den aktuellen Beobachtungen liegt das Kernproblem nicht einmal in der Menge von Information. Eine grosse Herausforderung ist die Auswahl der vielen Kommunikations- und Kollaborationswerkzeugen und dem Fehlen von Richtlinien, wie die Kanäle benutzt werden sollen.
Warum werden Tasks in einem Dokumentationswerkzeug erstellt und gepflegt? Wir pflügen auch nicht mit einem Sportwagen einen Acker. Der Highlevel-Prozess würde das vielleicht zulassen, denn um einen Acker zu pflügen, benötigen wir ein fahrbares Werkzeug. Leider ist mit einem Sportwagen in der dieser Anwendung niemandem geholfen. Im Gegenteil: Die Verwendung verursacht Mehrkosten durch höhere Wartung oder mangelnde Funktionalität.
Konkret heisst das, es lohnt sich kontinuierlich in die Qualität von schlanken, verständlichen und sinnvollen Prozessen und deren Implementierung in unserer Arbeitsumgebung zu investieren. Beim initialen Aufsetzen eines Teams wäre das eine leichte Aufgabe, wenn dem Thema die nötige Aufmerksamkeit geschenkt und Erfahrung im Aufsetzen solcher Konzepte vorhanden wäre.
Die Quintessenz aus diesen Beispielen liegt darin, dass Teams mit der richtigen Konzeption betreffend Anwendung von Werkzeugen befähigt werden. Dafür muss es sich einerseits darüber klar werden, welche Informationen für wen relevant sind und wie einfach man darauf zugreifen kann. Produktdokumentation gehört in ein Dokumentationswerkzeug, während Tasks in einem anderen Tool viel einfacher bearbeitet werden können.
Wie erwähnt sind die frühe Definition und die entsprechende Implementierung von Arbeitsvorgehen im Entwicklungsprozess eine lohnende Investition. Aber auch wenn ein Team schon lange zusammenarbeitet, ist eine regelmässige Überprüfung und Verbesserung der Effizienz unumgänglich. Das Retrospektive-Meeting ist für genau solche Beobachtungen gemacht worden, wird aber in wenigen Fällen dafür genutzt.
Die kontinuierliche Identifikation von Mehraufwänden (oder Waste) unterstützt das Team in der Effizienz und Effektivität. Wenn vermehrt die Frage nach Informationen auftaucht, ist das ein erster Anhaltspunkt für eine Verbesserung. Weitere Hinweise sind Fragen in Bezug auf Gültigkeit von Informationen (Redundanzen) und welche Entscheidung zu einer Nicht-Umsetzung einer Anforderung geführt hat. Die Anzeichen einer schlechten Prozessqualität spürt in erster Linie nicht die Kundin oder der Kunde, sondern das Team.
«Die Verantwortung für die Verbesserung liegt beim Scrum-Master», wird mir oft gesagt. Eigentlich ist die Frage nach Verantwortung überflüssig. Der Scrum-Master ist Teil des Teams und das Team braucht Zeit für eine Verbesserung. Es sollte im Interesse aller Beteiligten liegen, dass solche Impediments aus dem Weg geschafft werden können. Wenn dem Team diese Art von technischer Exzellenz fehlt, dann sollten alle nach Unterstützung in der Prozessdefinition fragen und diese auch erhalten.
Die Umsetzung der Verbesserungen findet auf einer ökonomischen (und agilen) Grundregel statt: Wir verbessern die Punkte, welche am wenigsten Aufwand generieren und den meisten Nutzen bringen. Schritt für Schritt und kontinuierlich im Sinne des Teams und den zu entwickelnden Produkten. Das hört sich auch nach einem wichtigen Teil des agilen Manifests an.
Bevor wir in dieser dot.Quality-Time Reihe zur effektiven Umsetzung kommen, wird im nächsten Beitrag der Zusammenhang zwischen Projekt- und Produktqualität betrachtet. Viele Firmen unterschätzen die Komplexität ihres eigenen Produktes, was meist erst bei der Integration über mehrere Lieferanten Einfluss auf den Erfolg hat.
Keine Kommentare bis jetzt
Lass uns wissen, was du darüber denkst.