Als nächstes in meiner Interview-Serie zum Thema Qualität und wie man sie von Beginn an integriert spreche ich mit dem erfahrenen Product Owner, Business Analysten, Requirements Engineer und Agile Coach, Benjamin (Beni) Wyss.
Pia: Hallo Beni, es freut mich, dass du dir heute Zeit nimmst, mit mir über Qualität und Built-in Quality zu plaudern.
Beni: Hallo Pia, herzlichen Dank für die Einladung, Ich freue mich sehr auf das Gespräch.
Pia: Wunderbar. Bevor wir starten, stell dich bitte kurz vor. Wer bist du und was machst du beruflich?
Beni: Benjamin ist der offizielle Name, aber gerne für alle Beni. Ich bin 37 Jahre alt und arbeite seit fast 20 Jahren als Business Analyst, Product Owner und Agile Coach.
Aktuell bin ich bei Infometis beschäftigt. Wir sind eine Beratungsfirma in Zürich und haben uns auf die Fahnen geschrieben, Qualität und Automatisierung bei unseren Kunden zu etablieren und zu implementieren.
2004 habe ich nach der Lehre zum Bankkaufmann als Business Analyst in klassischen Wasserfall-Projekten meine Karriere in der IT gestartet. Nach einigen Stationen in der Finanzindustrie bin ich schliesslich 2011/2012 das erste Mal mit einem agilen Projekt in Berührung gekommen. Als Business Analyst in einem Scrum-Team hatte ich sofort enormen Spass, weil ich endlich meine Leidenschaft für die Technik und die Analyse noch besser verbinden konnte.
Meine nächste Station führte mich als Product Owner zu einer Software-Entwicklungsfirma. Schnell musste ich lernen, mich mit Fragen wie:
“Wie gehe ich damit um, wenn ich zu viele Stakeholder-Anforderungen und grossen Lieferdruck habe? Wie soll das funktionieren, wenn ich dann noch die Qualität hochhalten muss?”
auseinanderzusetzen.
Ich habe damals sehr viel gelernt und gebe dieses Wissen nun bei Infometis in Kundenprojekten und als Coach weiter.
Privat bin ich verheiratet mit einer wunderbaren Frau 😇 und ein sehr neugieriger Mensch. Ich lese sehr gerne. Sei es über Physik, Chemie, Psychologie oder ein Thriller. Wenn ich gerade nicht lese, mache ich sehr gerne Sport.
Pia: Herzlichen Dank. Du hast es schon angeteasert, wie es dazu kommt, dass wir beide heute hier sitzen. Ja, wir sind verheiratet und weil du ein toller Ehemann bist und mich einerseits gerne unterstützt, und andererseits sind wir heute hier, wegen unserer gemeinsamen Leidenschaft für gute Software. Wir haben uns in der Arbeit kennengelernt und haben daher viele fachliche Berührungspunkte. Ausserdem tauschen wir uns gerne dazu aus.
Das als Information vorweg für unsere Leser:innen, falls der Umgangston stellenweise zu vertraut wird. Diese Tatsache macht unsere fachliche Diskussion sicherlich nicht minder interessant, höchstens ein bisschen kurzweiliger zu lesen.
Erzähl mal, Beni, was hältst du von Built-in Quality?
Was ist deine persönliche Interpretation davon? Was denkst du, was andere in deinem Geschäftsumfeld darunter verstehen?
Beni: Ich bin in erster Linie sehr froh, dass es diesen Begriff gibt. “Aufgewachsen” bin ich mit dem Begriff Testing. Und Testing ist die letzte Phase vor dem Release. Die Quality-Gates vorher sind oft formeller Natur, wie z.B. erfüllt die Spezifikation und das Design alle formalenKriterien? Ist Budget vorhanden? Usw.
Was aber, wenn dann etwas nicht funktioniert wie erwartet? Oder sich beim Testen die Erwartungen verändern? Oft musste ich verhandeln, ob etwas ein Fehler ist oder ob es “läuft wie besprochen”. Was mich aber immer verunsicherte: Was, wenn wir das Falsche besprochen haben?
Bei Built-in Quality gefällt mir, dass Qualität als Bestandteil des Produkts über sämtliche Phasen angesehen wird.
2006 habe ich das IREB Requirements Engineering Zertifikat gemacht. Im Kurs haben wir uns über den Wert von Requirements Engineering (RE) unterhalten. Eines der Hauptargumente war: Fehlerkosten vermeiden. Machen wir gescheites RE, dann passieren weniger Fehler. Damals war alles sehr auf Fehler fokussiert.
Es kann durchaus sein, dass wir das falsche Produkt, Feature etc. (technisch) völlig korrekt bauen. Es geht um zwei Dinge: «das richtige Produkt bauen» und «das Produkt richtig bauen».
Built-in Quality fasst hier meine Welt gut zusammen. Wir müssen Qualität von Anfang bis zum Ende denken. Aber was heisst eigentlich Qualität? Darüber müssen wir uns unterhalten, und das geht nur gemeinsam.
Pia: Ich würde gerne gerade einhaken, beim klassischen Requirements Engineering. Du hast gesagt, es ging darum es von Anfang an richtig zu machen, jegliche Fehler zu vermeiden. Wie hast du das früher gesehen und wie siehst du es heute?
Für mich ist es unglaublich viel verlangt von einer Person, als Business Analystin oder Requirements Engineer von Anfang an alles zu bedenken. Ist das überhaupt realistisch? Ist das sinnvoll, wenn man versucht das allein zu machen?
Beni: Nein, es ist nicht realistisch und nein, es ist auch nicht sinnvoll, es allein zu machen.
RE bedeutet insbesondere mit Stakeholdern zu sprechen. Früher war man der Meinung, die wissen ganz genau, was sie wollen.
Das zeigt sich auch beim Qualitätsmerkmal einer Spezifikation: der “Vollständigkeit”.
Ich bin der Meinung, dass dies nicht möglich ist. Dass es immer Iterationen und Feedbackschleifen braucht. Und diese sollen sich nicht (nur) auf Spezifikationen, sondern auf lauffähige, möglichst produktionsnahe Software beziehen.
Wenn ich etwas benutze, weiss ich, ob ich es haben will oder nicht. Ich sehe, ob es die Probleme löst, die ich habe, ob es benutzerfreundlich ist, ob ich die Funktionen finde, ob ich damit erfolgreich bin.
Mir wurde von einer Stakeholderin, auf die Bitte, mein Use Case-Diagramms zu reviewen, gesagt: «Ich werde nicht dafür bezahlt das zu verstehen».
Das hat mich stark geprägt. Die Stakeholderin will Software, die ihr hilft, ihren Job gut zu machen und nicht mein Diagramm überprüfen.
Darum bin ich kein Fan von up-front RE und ein grosser Freund vom kontinuierlichem RE.
Kontinuierliches RE bringt jedoch andere Herausforderung mit sich. Einerseits muss ich kontinuierlich Software liefern können, um darauf basierend die nächsten Anforderungen zu ermitteln. Zudem benötige ich das Commitment der Fachspezialist:innen. Sie müssen die Flexibilität mitbringen, kontinuierlich mit dem Team die Anforderungen zu hinterfragen. Das erfordert Zeit und Engagement. Beides ist nicht immer leicht zu bekommen.
Langfristig spare ich aber Zeit und Ressourcen, indem ich Verschwendung reduziere. Eine ehemals wichtige Anforderung ist heute möglicherweise gar nicht mehr so wichtig. Die dringendsten Probleme und vielversprechendsten Ideen werden zeitnah umgesetzt. Neue, bessere Ideen entstehen.
Dafür braucht es Zusammenarbeit, über Silos und Abteilungsmauern hinweg.
Pia: Absolut, ich bin total bei dir. Was ich heute gefühlt immer noch zu oft erlebe ist, was du auch beschrieben hast. Die Organisation ist schon agil unterwegs, es gibt aber nach wie vor diese Mauern.
In Bezug auf Testing bekomme ich z.B. von Tester:innen oder QA-Spezialist:innen Testfälle zum Review über die Mauer geworfen. Oder diese Personen sind dazu verpflichtet ihre Testfälle von Business Analyst:innen überprüfen lassen. Ich persönlich denke mir dann oft dasselbe, was deine ehemalige Stakeholderin gesagt hat: «Ich werde nicht dafür bezahlt eure Testfälle zu reviewen».
Kennst du das auch? Wie gehst du damit um?
Beni: Ich war mal der Böse und habe Testfälle reviewen lassen.
Pia: Die hast du geschrieben oder die hat dir ein Tester gegeben und du hast sie von jemand anderem überprüfen lassen?
Beni: Ich komme gleich darauf zurück.
Etwas reviewen zu lassen, es über die Mauer werfen, per E-Mail zu versenden, ist unglaublich ineffizient. Ich bin der Meinung, dass über Besprochenes geschrieben werden darf, aber über alles «offiziell» Geschriebene gesprochen werden muss.
Wenn ich als Business Analyst zwecks “Effizienz” gleich noch die Testfälle schreibe, ist dies kontraproduktiv. Ich beraube die Spezialist:innen der Kreativität, mit guten Fragen effektivere und bessere Testfälle zu finden, ich beeinflusse sie und ich werde zum Flaschenhals.
Oft wird diese Art von Diskussion als Verschwendung gesehen (die Tester:innen testen nicht, die Programmierer:innen programmieren nicht). Aber was sind schon 15 Minuten Diskussion gegenüber E-Mail öffnen, Excel anschauen und versuchen zu verstehen, was die/der Absender:in von mir will.
Derartige Diskussionen fördern zudem das explizite gemeinsame Wissen. Oft haben wir ein implizites gemeinsames Wissen. D.h. wir meinen, das gleiche zu verstehen oder eine Sache gleich zu interpretieren, aber das ist häufig nicht der Fall.
Beim expliziten, gemeinsamen Wissen ist das Risiko nicht Null, falsch zu liegen. Aber die Wahrscheinlichkeit, ein Missverständnis zu erkennen, ist im persönlichen Gespräch wesentlich grösser.
Oder wie es im Manifest für agile Software-Entwicklung heisst:
“Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.”
In einem ehemaligen Projekt gab es den sogenannten «Testfall Service». Im Sinne der Kosteneffizient war dieser im Ausland angesiedelt. Wir mussten die Spezifikationen senden und bekamen dafür Testfälle zurück. Ich habe also meine fertige, freigegebene Spezifikation versendet. Zurück kam die schiere Menge von 250 Testfällen. Der externe Service wurde ja auch nach Anzahl geschriebener Testfälle vergütet. Ich war mittel motiviert 250 Testfälle zu reviewen. Also habe ich mich dafür entschieden meine eigenen Testfälle zu schreiben. So war ich um einiges schneller als alles zu reviewen.
Damals habe ich vermisst, mit QA-Profis meine Spezifikation zu besprechen und zu challengen, um die Spezialist:innen anschliessend mit vollem Vertrauen die Testfälle designen zu lassen.
Pia: Krasse Geschichte und ich hoffe wir erleben solche Situationen bald gar nicht mehr und es geht in die Richtung, die du auch beschrieben hast. Du möchtest Spezialist:innen an deiner Seite die dich sowohl bei der Anforderungserhebung als auch beim Testing unterstützen sowie fordern.
Gerne möchte ich nun auf das Thema Wert eingehen. Man sagt gerne, eine User Story muss (Business) Value bringen.
Was bedeutet Value für dich? Was ist der Value einer User-Story?
Beni: Das ist beinahe eine philosophische Frage…ich versuche es 😊
Persönlich empfinde ich es als schwierig, User-Stories in iterationsgerechten Grössen mit einem konkreten, absoluten Wert zu versehen.
Bei der Diskussion über den Wert hilft mir das Nutzenmodell. Dieses besagt, dass es auf der rechten Seite die einfach messbaren, aber schwer zu beeinflussenden “Lagging Indicators” gibt. Zum Beispiel bei einer Videoplattform “Anzahl gespielte Minuten pro User”. Ich kann nicht einfach entscheiden, dass die User länger Videos schauen müssen. Aber ich kann es einfach messen. Auf der linken Seite sind die einfach zu beeinflussenden, schwierig messbaren “Leading Indicators”. Das könnte sein “User können Bonuspunkte für jede geschaute Minuten sammeln”. Dieser Leading Indicator kann implementiert werden.
Die Hypothese lautet: “Mit den Bonuspunkten erhöhen wir die Anzahl gespielte Minuten pro User und somit die Werbeeinnahmen.” Das ist der (Business-)Value, den ich mir verspreche. Damit ich diesen erreiche, müssen die User aber auch einen “Wert” von den Bonuspunkten haben. Sei es eine Rangliste mit Auszeichnungen, Gutscheine o.ä.... Das wäre dann der “User-Value”.
Wert ist darum immer eine Frage der Perspektive. Welchen “Wert” hat es, wenn ich auf meiner Webseite den Cookie-Banner implementiere? Für den User im besten Fall Transparenz, für mich als Unternehmer, dass ich gesetzeskonform agiere. Das ist auch eine Art Business-Value. Oder wenn ich mit einem Re-Design meine Wartungskosten senke. Auch das kann Business-Value sein.
Bei Stories sollte sich das Team daher darüber unterhalten: Wem macht die Umsetzung wie Freude? Und weil des einen Freud des andern Leid ist: Wie können wir allfällige negative Seiteneffekte verhindern?
Pia: Ja, macht absolut Sinn, was du sagst. Was mir jedoch im täglichen Arbeiten oft begegnet ist, dass alle derart fixiert, sind auf Business-Value, dass technische Stories nicht berücksichtigt werden.
Wenn ich beispielsweise als Testerin im Team eine Story für ein neues Testdaten-Set erfasse und ich es nicht spontan schaffe den Bogen zum Business-Value zu spannen, landet meine Story ganz hinten im Backlog.
Wie gehst du als Product Owner mit so etwas um?
Beni: Das war ein Lernprozess für mich. Es ist die klassische Feature-Falle. Wir wollen immer neue Funktionen bauen, weil wir oft daran gemessen werden. Da sieht die Kundschaft, wie «fleissig» das Team war.
Aber: Funktionen sind nur die Spitze des Eisbergs. Wenn wir versuchen Qualität zu definieren, und da orientiere ich mich gerne an ISO 25010, ist Funktionalität nur ein Attribut von vielen, welches die Qualität von Software ausmacht. Dazu kommen Wartbarkeit, Sicherheit, Benutzerbarkeit, usw. Wenn du mir als Testerin sagst, dass wir X brauchen um automatisiert testen zu können, zahlt das für mich ganz klar auf Wartbarkeit ein und hat genauso einen Wert, wie die funktionalen Anforderungen.
Diese oftmals nichtfunktionalen Dinge unter der Wasseroberfläche gehören unbedingt gemacht, auch wenn kein direkter Business-Value erkennbar ist. Tun wir diese Dinge nicht, können wir schon sehr bald gar keinen Business-Value mehr liefern. Eine unsichere Applikation will niemand kaufen. Eine nicht-wartbare Applikation kostet zu viel.
Als PO bin ich für das ganze Produkt verantwortlich. Und alle diese Qualitätsattribute unterstützen mich dabei, konkreten Business-Value zu liefern. Zudem sind die Kosten für ein Feature tendenziell tiefer, wenn ich eine stabile Basis habe und diese auch pflege.
Auch dürfen wir zwischendurch gerne Zeit darauf verwenden, das eigenen Produkt zu entschlacken mit Re-Factorings; d.h. ausbauen von nicht mehr benötigten Funktionen, aufräumen von redundanten Tests usw.
Ich habe die nicht-funktionalen Qualitätsattribute nicht immer so gesehen. Mittlerweile denke ich aber, dass diese Dinge mindestens gleich hoch, wenn nicht sogar höher zu priorisieren sind als manche funktionale Anforderung.
Pia: Absolut und es tut gut, dass von jemandem aus deiner Disziplin zu hören. Als QA-Spezialistin habe ich diesbezüglich oftmals das Gefühl gegen eine Wand zu reden.
Zum Abschluss möchte ich gerne auf ein Thema zurückkommen, welches du bereits kurz angesprochen hast: Implizites und explizites Wissen und die Diskussionen im Team, die es braucht, um Wissen explizit zu machen.
Oft erlebe ich, dass Diskussionen im Team nur innerhalb einer Disziplin stattfinden. Zum Beispiel sehe ich Entwickler:innen nur untereinander diskutieren. Sie trauen sich oft nicht dich als PO oder andere Disziplinen zu hinterfragen. Dasselbe gilt für Tester:innen und andere Rollen im Team.
Wie förderst du Diskussionen im Team, sodass sich deine Kolleg:innen trauen auch dich in Frage zu stellen?
Beni: Eine unglaublich gute Frage.
Ich habe das schon oft erlebt. In einem Team habe ich einmal etwas übertrieben gesagt: «Leute, ich bin dumm. Helft mir. Ich bin nicht der Allwissende.»
Als Business Analyst liebe ich Details und mache mir oft sehr früh viele Gedanken über Details und Lösungsideen. Auch in der Rolle als PO. Um trotzdem das Team so wenig wie möglich zu beeinflussen, habe ich folgende Taktik:
Ich teile nicht sofort alle meine Gedanken mit dem Team. Ich lasse Details zu Beginn bewusst weg und fokussiere mich nur auf die Erläuterung der Problemstellung. Dann lasse ich das Team mögliche Lösungen diskutieren. Manchmal verlasse ich auch den Raum und lasse mir anschliessend vom Team ihre Lösungsideen zeigen. Dann vergleichen und diskutieren wir meine und ihre Ansätze. Das muss man sich als PO bewusst sein. Diese Diskussionen und Lösungsideen muss man explizit einfordern und auch den Raum entsprechend gestalten, dass das Team nicht in eine bestimmte Richtung gedrängt wird.
Pia: Absolut, ja! Ich hoffe das ganz viele Product Owner:innen unsere Unterhaltung lesen werden. Ich denke viele trauen sich das nicht. Viele glauben, sie müssten alles wissen. Das finde ich sehr schade. Ich denke, dass jede/r, egal in welcher Position oder Rolle, davon profitiert, wenn wir im Team über Dinge diskutieren und so gemeinsam besser werden. Ich halte es für eine absolute Stärke auch mal sagen zu können, dass man etwas nicht weiss und so andere im Team dazu zu ermutigt sich aktiv mit ihren wichtigen Skills einzubringen und mit dem Produkt auseinander zu setzen.
Um unser heutiges Thema abzurunden, könntest du für unsere Leser:innen nochmal zusammenfassen, was für dich die wichtigsten Dinge im Hinblick auf Qualität und Built-in Quality sind? Was sollte man berücksichtigen? Woran sollte man sich halten?
Beni:
Nummer 1 ist für mich der Teamsport-Gedanke, den ich als PO oder BA aktiv fördern kann.
Das ist die Kommunikation, das gemeinsame Erarbeiten, gemeinsam coole Software bauen und sich über Qualität und deren Bedeutung im eigenen Kontext auszutauschen.
Nummer 2 ist der Gedanke von schlanken Funktionen und Applikationen.
Mit einfachen Mitteln Probleme lösen, nicht jedes Problem lösen und die Lösungen für Probleme, die es nicht mehr gibt, wieder aus der Applikation zu entfernen. Schlank bleiben ist die Devise.
Nummer 3 ist Kontinuität. Langsam ist geschmeidig und geschmeidig ist schnell.
D.h. was wir tun, machen wir richtig, mit allen Qualitätsmerkmalen, die uns wichtig sind. Wir fördern eine stabile Applikation. Auf diese bauen wir den Business-Value. Das tun wir kontinuierlich und in einer Pace, die wir langfristig halten können und nicht unter ständigem Zeitdruck.
Pia: Ausgezeichnet, vielen Dank dafür. Ich schliesse mich zu 100% an. Vielen Dank auch für das wunderbare Bild mit dem Eisberg. Das hilft mir definitiv und ich hoffe auch unseren Leser:innen.
Wenn mich in Zukunft jemand fragt, wo der (Business-) Value ist, werde ich mich auf den Eisberg beziehen. Wenn wir uns immer nur auf die Spitze konzentrieren können wir unsere User:innen und Stakeholder:innen nicht dauerhaft zufriedenstellen.
Beni: Dann würden wir untergehen…
Pia: Ich hoffe nicht wie die Titanic…
Herzlichen Dank für das superspannende Gespräch.
Gibt es etwas, das du unseren Leser:innen noch mitgeben möchtest?
Beni: Herzlichen Dank, dass ich hier meine persönliche Meinung und Erfahrungen teilen durfte.
Ach ja, und:
Die Minute ist wichtig. Die Sekunde geht oft nach hinten los.
