Agile Metriken als strategisches Element für den Projekterfolg

Noch immer herrscht die weitläufige Meinung, dass absolute Zahlen bezogen auf die Produktqualität (z.B. Anzahl der Fehler) oder Sprint-Qualität (z.B. Anzahl erfolgreich geschlossener Stories) ausreichen um effektiv und effizient das Testing steuern zu können. Die zweite Informationsebene zum operativen Test Management ist die Priorisierung der Fehler. Meistens in Stufen von eins bis vier, oder in Kategorien von A bis D. An dieser Stellte sei angemerkt, dass hier nicht die Kategorisierung des Risk-based Testing (RBT) gemeint ist. RBT wird in der Testvorbereitung zur Priorisierung der Testausführung eingesetzt. In der Ergebnisbetrachtung, nach Testausführung, wird RBT herangezogen, um das Restrisiko anhand der verbliebenen Testfälle und offenen Fehler zu bestimmen. Ich möchte nicht verheimlichen, dass ich ein grosser Fan von RBT bin.

Besser als bei jeder Status-Ampel kann man zu jedem Zeitpunkt berechnen, wie hoch das Restrisiko wäre, wenn man in diesem Augenblick das Testing abbrechen würde. Das halte ich für sehr transparent und ermöglicht Ressourcen zielgerichteter einzusetzen. Auf RBT werde ich noch wesentlich ausführlicher in einem weiteren Beitrag eingehen. Hier soll es um Metriken im agilen Umfeld gehen. Ich plädiere für ein Vorgehen, dass ähnlich der rückwärts gewandten Planung entspricht. Was ist das Ziel und wie kommen wir dort hin? Damit wird verhindert, dass ein für agile Teams zu entwerfender Metrik-Katalog zu einer akademischen Übung wird.

Aus Sicht der IT ist der GQM-Ansatz (Goal – Question – Metrik) schon sehr alt. Dennoch stellt dieser Ansatz immer noch das effektivste und effizienteste Vorgehen dar, um nicht nur Lebenszyklen von Produkten, sondern auch die damit verbundenen Entwicklungs-, Support- und Management-Prozesse messbar zu machen. Mit dem GQM-Ansatz hat man einen Blueprint, um in transparenter Weise sinnvolle und vor allem zielführende Metriken zu etablieren die Sprint-übergreifend Verbesserungen ermöglichen. Erst mit dieser Toolbox ist man am Ende eines Sprints, der in etwa einem PDCA-Zyklus entspricht, in der Lage eine objektive und vor allem einheitliche Bestandsaufnahme bezüglich der Produkt- und Prozessqualität durchzuführen. Mit der Messung des aktuell abgeschlossenen Sprints und der historischen Betrachtung sämtlicher zuvor durchgeführten Sprints lässt sich das verbleibende Verbesserungspotential in Form von Kennlinien eruieren. Die Anwesenheit von Metriken würde salopp gesagt den Ansatz “Von der Hand in den Mund leben” implizieren. Ich plädiere für ein Metrik-System, dass über einen Release, einen Sprint oder sogar über den Lebenszyklus eines Produkts hinaus geht, und die Vision einer kontinuierlichen Verbesserung unterstützt.

image-20210510-072731

Eine Vision, wie in etwa “Wir wollen Qualität teilen” könnte zum Beispiel in Ziele resultieren, die mit jeder Produktivsetzung eines Inkrement die Fehlerrate um 15% gesenkt wird. Ein weiteres Ziel könnte sein, dass das Produkt bis zum Going-Public von 100% aller Mitarbeiter innerhalb des Unternehmens eingesetzt wird. Als Beispiel aus der Vergangenheit sei hier Microsoft Word angeführt. Alle Microsoft-Mitarbeiter haben Word vor Verkaufsstart eingesetzt. Die Qualität wurde im wahrsten Sinnes des Wortes geteilt (“Eat your own dog food”). Positives wie negatives Feedback wurde dementsprechend schnell an das Produkt-Team zurück gegeben. Vielleicht war man damals nicht nur deshalb schon viel näher am agilen Vorgehen dran, sondern auch deshalb weil die Teams mehr oder weniger autarke Einheiten waren bei denen auch der Projektleiter programmiert hat. Unter Berücksichtigung des hier im Artikel beschriebenen Inhalts, bekommt man einen sehr strukturierten Verbesserungsansatz dessen Lücken noch durch geeignete Metriken gefüllt werden müssen.

Ich betrachte jede verwendete Metrik und jede Messung auch aus strategischer Sicht und nicht nur um das aktuelle Problem zu lösen. Dabei geht es zum Beispiel nicht nur um das Verhältnis zwischen geplanten und erfolgreich durchgeführten Sprints, sondern auch um eine Kategorisierung und Häufigkeit der Probleme offener Stories am Ende der Sprints. Es geht nicht nur um Sprint Burndown Charts, sondern auch um eine Pareto-Betrachtung der aktuellen Arbeitssituation. Wie hoch ist der Anteil an Blockern und welcher Art sind diese? Es geht auch um das Verhältnis zwischen den realisierten Features und den damit verbundenen Testing-Aufwänden. Wie oft müssen damit verbundene Defects wiederholt behoben werden bis der Kunden zufrieden ist? Die Liste der möglichen Metriken ist abzählbar unendlich, wie der Mathematiker sagen würde. Die Liste der sinnvollen Metriken ist abzählbar und bedient nur und ausschliesslich die zuvor definierten Ziele. Die ausgewählten Metriken sollten Team- und Produkt-übergreifend und auf jeden Fall strategischer Natur sein.

Kontakt

Harald Schmidt

Harald Schmidt

Mobil: +41 (0) 79 88 55 1 44
E-Mail: harald.schmidt@spf-consulting.ch

Wie Du von agilen Werten als Navigationssystem virtueller Kollaboration profitierst.

agile Werte in virtueller Kollaboration

Agile Werte sind in aller Munde. Fokus, Respekt, Offenheit und vieles andere ist zu hören. Tatsächlich sind allgemein gültige Werte enorm wichtig, gerade bei virtueller Zusammenarbeit. In diesem Artikel erfährst du, warum das so ist und wie du Zusammenarbeit in deinem Team mit agilen Werten aktiv gestalten kannst.

Agile Werte – elementarer Bestandteil virtueller Teamarbeit

Die im Zuge der Corona Bekämpfung eingeführte Homeoffice-Pflicht hat uns in das Zeitalter virtueller Teamarbeit katapultiert. Doch diese Form der Zusammenarbeit dient nicht nur der Viruseindämmung. Sie hat weitere Vorzüge, die darüber fast in Vergessenheit geraten sind. Virtuelle Zusammenarbeit bietet die Möglichkeit, Personen mit den besten Fähigkeiten und Kompetenzen – völlig unabhängig von ihrem Aufenthaltsort – zusammen zu bringen, um erfolgreich ein gemeinsames Ziel zu erreichen.

Sicherlich bestimmen fachliche Qualifikationen massgeblich, wie effizient ein Team sein Ziel erreicht. Doch ein weiterer Faktor für die Zielerreichung ist die Qualität der virtuellen Kollaboration. Dabei spielen agile Werte eine wichtige Rolle, wie das folgende Beispiel zeigt.

Vor einiger Zeit arbeitete ich in einem Team, das sich auf Standorte in der Schweiz und in Indien verteilte. Alle waren sehr gut ausgebildete Spezialisten. Die Aufgabe der Inder war es, Dashboards zu programmieren. Diese erstellten sie stets in hoher Qualität. Doch nach einiger Zeit der Zusammenarbeit wunderten wir uns in der Schweiz, warum manche Visualisierungen so lange dauerten. Als wir die Inder darauf ansprachen, erklärten sie uns, dass diese Visualisierungen kompliziert umzusetzen seien. Zwar hätte es jeweils eine Möglichkeit zur einfacheren Umsetzung gegeben. Diese hätte jedoch geringfügige Änderungen im Layout des Dashboards zur Folge gehabt. Diese Erklärungen der Inder erstaunte uns. Wir fragten sie, warum sie ihre Ideen zur effizienteren Vorgehensweise nicht vorgeschlagen hatten. Diese Frage wiederum erstaunte die Inder. Sie erklärten uns, dass sie alles wie beauftragt umsetzen wollten. Es sei für sie nicht üblich, Aufträge zu hinterfragen und eine Diskussion über mögliche Umsetzungsvarianten anzuregen.

Für die indischen Kollegen hatte der Wert ‘Fokus’ einen sehr hohen Stellenwert. Sie fokussierten sich auf das gewünschte Ergebnis. Dagegen war für uns in der Schweiz der Wert ‘Offenheit’ völlig selbstverständlich. Wir waren daran gewöhnt, mögliche Umsetzungsvarianten offen zu thematisieren. Jeder agierte aufgrund seiner Werte. Allerdings ohne sich dessen bewusst zu sein. Erst nach einiger Zeit wurden Unterschiede in der Vorgehensweise offenbar. Die unterschiedliche Handhabung der agilen Werte war offensichtlich geworden.

An diesem Beispiel wird die Funktion der agilen Werte deutlich: Es sind Regeln für die Zusammenarbeit im Team. Sie wirken wie Leitplanken, innerhalb derer sich jedes Teammitglied frei bewegen kann. Damit geben sie Orientierung und Sicherheit. Zudem machen Werte spürbar, was alle innerhalb des Teams miteinander verbindet. Sie wirken sinnstiftend und motivierend. Nicht zuletzt unterstützen sie den Aufbau von Vertrauen innerhalb des Teams.

Agile Werte als Schatz an Kreativität und Potenzial

Wie wir gesehen haben, spielen neben der fachlichen Qualifikation auch agile Werte eine massgebliche Rolle. Beides ist wichtig, damit ein Team mit seiner virtuellen Kollaboration über mehrere Länder hinweg erfolgreich seine Ziele erreicht. Natürlich gilt diese Aussage auch für die virtuelle Teamarbeit innerhalb eines Landes. Auch wenn sich ein Team ausschliesslich im gleichen Land befindet, spielen agile Werte eine wichtige Rolle.

Doch die Bedeutung der Werte nimmt zu, je mehr Menschen aus unterschiedlichen Ländern zusammenarbeiten. Warum? Je mehr Länder, desto grösser die Unterschiede in den Werten. Eine grosse Vielfalt von Werten vergrössert das Spektrum an Kompetenzen im Team. Je mehr Werte es in einem Team gibt, desto grösser ist die Anzahl möglicher Handlungsoptionen. Es ist ein Schatz an Kreativität und Potenzial, den es zu heben gilt.

Wie du von agilen Werten profitierst

Wenn du mit deinem Team von der agilen Wertvielfalt profitieren möchtest, solltest du die agilen Werte gemeinschaftlich erarbeiten, aktiv leben und hinterfragen. Werte sind lebendige Elemente einer virtuellen Kollaboration.

Folgendes Schaubild verdeutlicht den Zusammenhang zwischen Werten, virtueller Kollaboration und einem gemeinschaftlichen Ziel.

 Zusammenhang_Werten_Ziel

Ausgangspunkt ist die Frage, mit welchen Werten du und dein Team eure Zusammenarbeit gestaltet, um das Teamziel bestmöglich zu erreichen. Daraus resultiert ein Set von agilen Werten als kraftvolle Unterstützung in der virtuellen Kollaboration. Im optimalen Zusammenspiel von Zusammenarbeit, fachlicher Qualifikation sowie einiger anderer Faktoren wie beispielsweise Budget oder Infrastruktur habt ihr die besten Voraussetzungen, um euer Ziel zu erreichen.

Dieser Sachverhalt lässt sich gut mit einem Navigationssystem vergleichen:

 8d81e705-9169-4748-ac17-507f7f4c8f85

Wer mit einem Navi sein Ziel in gewünschter Weise erreichen möchte, muss neben dem Ziel verschiedene Parameter definieren. Nur mit diesen Angaben kann das Navi die optimale Reiseroute zum Ziel bestimmen: Mit der minimalen Fahrtzeit, mit der kürzesten Strecke, ohne Autobahnen zu nutzen oder unter Vermeidung gebührenpflichtiger Strassen. Das Navi stellt sicher, dass man sein Ziel in der gewünschten Weise erreicht. Natürlich kommt man auch ohne Navi zum Ziel. Doch man riskiert Irrwege. Beispielsweise kann man leicht auf gebührenpflichtige Strassen geraten, obwohl man sich das Geld dafür doch eigentlich sparen wollte. Oder man fährt über Landstrassen, obwohl man es eilig hat.

Welche Parallelen gibt es zwischen agilen Werten und einem Navigationssystem?

Wie ein Navi benötigt auch ein Team ein Ziel, das es erreichen möchte. Was beim Navi die Parameter zum Errechnen der Reiseroute, sind beim Team die Werte: Sie ermöglichen unterschiedliche Wege zum Ziel. Beispielsweise kann ein Ziel durch fokussiertes Realisieren der gewünschten Lösung erreicht werden. Oder durch einen offenen Austausch möglicher Umsetzungsideen mit anschliessendem Entscheid für die beste Variante. Durch die Wahl geeigneter Werte kann ein Team seine Teamziele effizient erreichen.

Genauso wie sich das Reiseziel ohne Navi erreichen lässt, kann auch ein Team seine Ziele realisieren, ohne sich um die Werte zu kümmern. Und auch hier können unerwünschte Konsequenzen auftreten. Beispielsweise setzt man einen komplizierten Lösungsansatz um, obwohl man doch eigentlich schnell fertig sein wollte. Oder man verliert sich in Diskussionen, obwohl man das Ziel zielstrebig umsetzen wollte.

Man kann agile Werte wie ein Navigationssystem nutzen, um sein Ziel bestmöglich zu erreichen. Damit dies gelingt, solltest du die folgenden drei Punkte beachten:

Unterschiedliche agile Werte dürfen bleiben

Jedes Teammitglied bewertet die agilen Werte unterschiedlich. Eine Person findet Mut sehr wichtig, für eine andere geht nichts über Autonomie und eine Dritte schwört auf Selbstverantwortung. Das ist normal und völlig in Ordnung. Diese Unterschiede dürfen bleiben! Kein Wert ist per se falsch – die ausschlaggebende Frage ist immer, ob ein Wert in einer spezifischen Situation dem Erreichen des gewünschten Ergebnisses dient. Deshalb ist es wichtig, dass jedes Teammitglied die jeweils weniger favorisierten Werte als Kompetenzen betrachtet, keinesfalls als Problem. Denn mit einer ‘Problembrille’ stellen sie ein Hindernis dar, keine Ressource. Damit stehen diese Kompetenzen de facto nicht zur Verfügung.

Agile Werte transparent machen

Oftmals sind Werte so selbstverständlich geworden, dass man sie nicht mehr bewusst wahrnimmt. Sie sind nur implizit vorhanden. Man kommt gar nicht auf die Idee, dass es anders sein könnte. Wie im Beispiel unserer schweizerisch-indischen Teamarbeit. Die Mitarbeitenden in der Schweiz waren blind im Bezug auf ihre Offenheit, genauso wie die Mitarbeitenden in Indien hinsichtlich dem Wert ‘Fokus’.

Deswegen reicht es nicht aus, nur über agile Werte zu sprechen. Sind Werte nur implizit vorhanden, sind sie für den Verstand nicht greifbar. Wie lassen sich diese Werte transparent machen?

Eine Möglichkeit besteht darin, unerwünschte oder irritierende Verhaltensweisen zu thematisieren. So, wie wir es mit unseren indischen Kollegen taten. Sind unterschiedliche Wertvorstellungen offensichtlich geworden, beginnt ein Aushandlungsprozess im Team. Die Frage lautet: ‘Mit welchem Wert kann das gemeinschaftliche Ziel bestmöglich erreicht werden?’ Darauf ist eine Antwort zu finden. Der Nachteil bei dieser Vorgehensweise besteht darin, dass man sie erst dann durchführen kann, wenn etwas im Argen liegt.

Wer diesen Nachteil nicht in Kauf nehmen möchte, kann alternativ eine ‘Werte-Auktion’ durchführen, wie sie auch von SPF Consulting in dem Workshop Agile Werte als Essenz virtueller Kollaboration angeboten wird. Dieses Vorgehen umfasst eine bewusste Reflexion der Werte sowie die Ersteigerung der Werte in einer spielerischen Form. Dadurch werden sowohl die bewussten wie auch die impliziten Werte einbezogen. Es ist eine schnelle und kreative Form der Auseinandersetzung mit agilen Werten.

Egal, welchen Weg du wählst: Nur wenn du agile Werte transparent machst, kannst du sie in deinem Team in kraftvoller Weise nutzen.

Agile Werte situationsadäquat einsetzen

Es versteht sich nun fast schon von selbst, dass agile Werte nicht per se richtig oder falsch sind. Es kommt immer auf den Kontext an. Deswegen sollten wir besser von Werten sprechen, die einer Situation angemessen sind und dazu beitragen, das gewünschte Ergebnis zu erreichen. Oder eben nicht. Das gilt übrigens auch für die Zuordnung der Werte in ‘agil’ und ‘nicht-agil’. Auch in einem agil arbeitenden Team kann es durchaus sinnvoll sein, Werten zu folgen, die typischerweise als nicht-agil gelten. Ich denke da beispielsweise an den Wert ‘Disziplin’. Dieser ist durchaus hilfreich, wenn es darum geht, ein Backlog vollständig und aktuell zu halten sowie die Zeremonien immer wieder effizient und effektiv durchzuführen.

Agile Werte – wertvolles Potenzial, das du nutzen kannst

Agile Werte sind ein Erfolgsfaktor für die virtuelle Kollaboration. Gleich einem Navi, das hilft, ein Reiseziel zu erreichen, helfen agile Werte, die digitale Zusammenarbeit deines Teams in kraftvoller Weise zu gestalten. Wahrscheinlich besteht das Kunststück darin, das richtige Mass an Wertevielfalt zu finden, um dieses Potenzial gewinnbringend zu nutzen.

Dein Kontakt

Bild von Regine Stopka

Regine Stopka
Email: regine.stopka@spf-consulting.ch
Kontakt: https://www.spf-consulting.ch/kontakt/

Ist der Test-Manager in agilen Projekten obsolet?

Früher war alles besser! Bekanntlich nicht. Früher war alles anders und das war auch gut so. Ansonsten gäbe es keine Weiterentwicklung, und das ist durchaus positiv gemeint. Hinsichtlich der Transformation von stringenten und separierten Wasserfall-Teams hin zu einer agilen Entwicklungsorganisation werden heute wohl die wenigsten bestreiten, dass dies ein positiver Schritt bezüglich der Effizienz und Effektivität von Teams und ihren Ergebnissen für den Kunden war und ist. Mit der Selbstorganisation von Scrum-Teams und der damit verbundenen Philosophie von Arbeitsteilung und Teamgeist werden auch verständlicherweise die klassischen Rollen überprüft. Das gilt nicht nur für den Projektmanager und den Requirements-Engineer, sondern auch für den Test-Manager und seinem klassischen Verantwortungsbereich. Betrachtet man die Struktur des Testings und die Rolle des klassischen Test-Managers sieht man, verglichen mit dem Entwicklungsteam, eine eigenständige Projektorganisation, die der Entwicklung meist in Form eines Service mit der Aufgabe die Qualität sicherzustellen angegliedert ist.

Blog 01

Jetzt könnte man meinen, dass sich mit der Etablierung von Scrum-Teams und der damit verbundenen Selbstorganisation die Rolle und damit verbundene Aufgabenspektrum des Test-Managers nicht mehr notwendig und damit obsolet sei. Das glaube ich nicht. Mit der Annahme, dass die Performance von Scrum-Teams anhand ihrer Sprint-Performance gemessen wird und am Ende eine Sprints immer ein produktreifes Deliverable steht welches nicht unbedingt in Produktion gehen muss, ist ein Interessenskonflikt vorprogrammiert. Aus eigener Erfahrung sollte kein Entwickler seinen eigenen Code testen. Ausserdem wird das Thema Test Driven Development (TDD) in seiner ursprünglichen Idee nur unzureichend in die Teams integriert. Zu oft trifft man auf den Ansatz Dev first, Test later an. TDD erfordert ein hohes Mass an Disziplin und sehr starke Nerven, da der Entwickler bis zum Schluss die rote Ampel der Unit-Test-Suite sieht. Es erfordert ein stabiles Nervenkostüm, weil sich der Entwickler unter Umständen auch irgendwann fragen muss, ob der implementierte Test auch korrekt ist. Diskussionen wie zum Beispiel “Wer testet den Tester” kommen einem da in den Sinn. Zurück zur Rolle des Test-Managers in der neuen agilen Welt. Aus meiner Sicht wandelt sich die Manager-Rolle mit Budget-, Ressourcen- und Ergebnisverantwortung zu einer Coaching-Rolle, die innerhalb der Scrum-Teams durch seine methodische Expertise und das aktive Mittesten erheblich zur Qualitätssicherung und der damit verbundenen Kanalisierung von identifizierten Abweichungen zur Steigerung der Produktivität beitragen kann. Ich würde noch einen Schritt weiter gehen und die Rolle des aktiven Test-Coaches Team-übergreifend etablieren, um einheitliche Methoden und Quality Gates für die gesamte Scrum-Organisation zu definieren. Dies fängt bei der Formulierung von Checklisten und Reviews für die Annahme von Anforderungen für einen Sprint an und könnte final bei der Bereitstellung von automatisierten Regressionstests enden.

Blog 02

Der ehemalige Test-Manager wird in seiner Rolle zu einem festen und flexiblen Bestandteil der Scrum-Teams und fungiert als Coach, Mentor und Ideengeber für eine effiziente und effektive Qualitätssicherung. Er sollte auch einen fachlichen Heimathafen haben, der ihm die Möglichkeit gibt seine methodischen Erfahrungen und neuen Ideen direkt in die Praxis umzusetzen. Dies unterstützt den heutigen Best Practice Ansatz und schafft Evidenzen die zeigen, inwiefern sich Methoden und Erfahrungen für einen spezifischen Kontext umsetzen und in anderen Teams etablieren lassen.

Dein Kontakt

Harald Schmidt

Harald Schmidt
Email: harald.schmidt@spf-consulting.ch
Kontakt: https://www.spf-consulting.ch/kontakt/