Liefern Lieferanten nur Software oder auch Qualität? 

Arbeitest du in einem agilen Projekt mit Lieferanten oder Implementationspartnern zusammen und beeinflusst dies eure Produktqualität negativ?

Ist bei deinem Projekt bzw. Produkt unklar, welche Testing-Aufgaben der Lieferant und welche der Kunde durchführen muss?

Wenn du eine der Fragen mit «ja» beantworten kannst, dann bist du nicht allein. Im folgenden Artikel erfährst du mehr über die Ursachen und vor allem über Massnahmen, wie du deine Situation verbessern kannst!

In der Praxis trifft man auf sehr unterschiedliche Konstellationen der Zusammenarbeit. Mit externen Partnern, zum Teil auch mit mehreren Firmen in einem Projekt. In diesem Blog werden wir speziell folgende Konstellationen betrachten:

• Konstellationen, bei welchen innerhalb einer agilen Projekt- oder Produktorganisation mit einem externen Implementationspartner zusammengearbeitet wird.
• Konstellationen, bei welchen der substanzielle Teil des Projekts entweder selbst entwickelt oder als Standard-Software mit Customizing geliefert wird.

Verstärken sich aktuell Qualitätsprobleme in der Zusammenarbeit mit Lieferanten?

«Die Zusammenarbeit mit Lieferanten beim Testing in Agilen Projekten bereitet Probleme. Diese Problematik hat negative Auswirkungen auf die Lieferqualität.», dieses Feedback erhalten wir immer häufiger von unseren Kunden.

Ein Grund dafür ist, dass man tendenziell häufiger auf Standard-Software statt Eigenentwicklungen setzt. So kommt man schneller und effizienter zum Ziel. Andererseits verursacht der Wechsel hin zu agilen Entwicklungsformen Unklarheiten. Die agilen Frameworks (Scrum, Scaled Agile Framework etc.) berücksichtigen die Zusammenarbeit mit Lieferanten nicht out-of-the-box. Der Wasserfall-Prozess mit dem Abnahmetest sieht dafür eine spezifische Methodik vor. Der sehr spät im Projekt vorgesehene Abnahmetest bringt wiederum seine eigenen Probleme und Nachteile mit sich.

Im Agilen Umfeld verschärft sich das Problem durch die Tatsache, dass idealerweise ein einziges Team die Entwicklung und das Testing verantwortet. So kann möglichst früh und effizient ein shift left durchgeführt werden. Diese tiefe Integration lässt sich mit externen Lieferanten selten bewerkstelligen und bringt folglich diverse Probleme wie z.B. Medienbruch, Wechsel von Verantwortungen, Übergabeverluste und weiteres. Fehlende oder mangelhafte Release-Notes sind eine häufig anzutreffende Folge davon. 

Viele der hier erwähnten Probleme in der Zusammenarbeit mit externen Lieferanten treffen aber auch zu, wenn interne Lieferanten (z.B. eine Abteilung, andere Prozesse) andere Rhythmen und Vorgehensweisen benutzen als das Hauptprojekt. Deshalb sind die folgenden möglichen Massnahmen auch dort prüfenswert.

Wie sieht es in deinem Umfeld aus? Wie funktioniert in deinem agilen Projekt die Zusammenarbeit mit Zuliefer-Firmen? Arbeitest du in einer Konstellation, die hier überhaupt nicht erwähnt ist? Wenn ja: hat sich die Konstellation in deinem Kontext bewährt? Sehr gerne möchte ich mehr darüber erfahren! Nutze hierzu bitte die Kommentarfunktion.

Ursachen der Qualitätsprobleme bei Zusammenarbeit mit Lieferanten

Auf der Suche nach den Ursachen zeigen sich viele, und je nach Projekt sehr unterschiedlich gelagerte Gründe:

Verträge

Verträge mit Lieferanten (z.B. SLAs, Fix-Preis-Projekte) bilden ein Ursachen-Cluster mit sehr grossen Auswirkungen. Aber auch das grundsätzliche Setup der Zusammenarbeit (Arbeitsorte, Arbeitsweisen, Aufwandschätzungen etc.) hat grossen Einfluss auf die Arbeitsweise und deren Qualität. Zumal bei diesen frühen Entscheiden selten jemand seitens Testing bzw. von der Entwicklung involviert ist.

Soft Factors

Erstaunlich viele Ursachen lassen sich in den «Soft Factors» finden. Z.B. mangelhafte Kommunikation, kulturelle Unterschiede von Unternehmen und Personen, aber vor allem auch mangelndes Know-how bzw. Erfahrungen mit dem Testing auf beiden Seiten.

Anforderungs-Management & Akzeptanzkriterien

Einen weiteren Schwerpunkt bilden Ursachen im Bereich des Anforderungs-Managements, dem Beschrieb von Akzeptanzkriterien, der Definition und Durchsetzung der DoR (Definition of Ready) und vor allem DoD(Definition of Done). Mit unklaren Anforderungen lässt sich schlecht entwickeln und noch schlechter testen.

Entwicklungs- und Testprozesse 

Entwicklungs- und Testprozesse des Lieferanten wie auch des Auftraggebers haben einen sehr grossen Impact. Je nachdem wie sie gelebt werden, wie sie zeitlich strukturiert sind und vor allem wie flexibel sie sich aufeinander anpassen.

Lieferqualität

Wenn der externe Partner nicht von sich aus eine hohe Lieferqualität als ein Hauptziel anstrebt, dann besteht ein grosses Risiko, dass er die Software «über die Hecke wirft». Dann muss der Kunde sehr viel für die Verbesserung der Qualität des Produkts investieren. Dieses Vorgehen sehen wir in der Praxis leider sehr häufig. Es verursacht schlussendlich sehr hohe Aufwendungen beim Lieferanten (Bugfixing) wie auch Kunden (Testing), bei unterdurchschnittlicher Qualität.

Viele der obigen Themen werden verstärkt, wenn Lieferant und Besteller stark abweichende grundsätzliche Ziele/ Interessen verfolgen. Z.B. bezüglich Vorgehen, Ressourcen, Terminen sowie Kosten, aber auch der Art der Zusammenarbeit.

Erlebst du in deinem Alltag weitere Ursachen, die zu Problemen und schliesslich schlechterer Produktqualität führen? Dann lies weiter – im nachfolgenden Kapitel findest du geeignete Massnahmen und Anregungen zur Verbesserung deines Arbeitsumfeldes.

Massnahmen zur Verbesserung der Qualität in Projekten mit Lieferanten

Bei der Analyse möglicher Massnahmen zeigt sich, dass diese oft an einen bestimmten Punkt des Projekt- bzw. Produkt-Lifecycles gebunden sind oder dort die beste Wirkung entfachen. Hier deshalb eine chronologische Auflistung:

Vor / beim Start des Projektes/Produktes

Viele der effektivsten und nachhaltigsten Massnahmen müssen in der Früh- oder sogar Vorphase des Projekts beeinflusst werden. Dazu gehören zum Beispiel Verträge mit dem Lieferanten. Darin definieren sich viele der kritischen Parameter für die Zusammenarbeit:

Qualität

Bereits bei der Auswahl eines externen Dienstleisters sollte das Thema Qualität relevant sein. Um mehr über die Einstellung zum Thema Qualität zu erfahren, werden Befragung von Referenzen durchgeführt, Feedback aus dem Testing-«Netzwerk» eingeholt oder eine gemeinsamer Workshop gemacht. Alternativ können klar definierte Kriterien bezüglich Qualität in der Ausschreibung unterstützend wirken.

Verantwortlichkeit

Verantwortlichkeit im Vertrag bzw. mittels SLA etc. klar regeln. Welche Verpflichtungen bezüglich Testing hat der Lieferant? Testdurchführung, Testprotokolle, Releasenotes, Testautomatisierung? Wie, wann und wer dokumentiert, bzw. misst? Was passiert, wenn Vorgaben nicht erfüllt werden?

Mitarbeiter 

Da Entwicklungsprojekte stark von Know-how und Erfahrung abhängig sind, ist es wichtig, die benötigten Qualifikationen bereits im Vertrag zu regeln. In der Praxis sind immer wieder Projekte zu beobachten, bei welchen zu wenig Seniorität und Praxis-Verständnis vorhanden sind. Dadurch entstehen Probleme. Fordere wenn möglich einen dedizierten professionellen Tester seitens Lieferanten. Falls nicht vorhanden, kann diese Aufgabe ein Test-Consultants einer Drittfirma, wie z.B. SwissQ, übernehmen.

Testing-Ressourcen

Ausreichend Testing-Ressourcen, idealerweise ausschliesslich für das eigene Projekt arbeitend, sollten auch bereits im Vertrag definiert werden.

Personalfluktuation

Leider ist Personalfluktuation auch bei externen Dienstleistern eine Tatsache. Im Falle eines Wechsels sollten im Vertrag klare Übergabemodalitäten definiert werden. Zudem hilft eine saubere Projektdokumentation bei einer schnelleren und selbständigeren Einarbeitung neuer externer (aber auch interner) Mitarbeiter.

Defects

Sehr wichtig ist auch eine einfache Regelung bezüglich Defects. Wie Defects zu priorisieren sind und bis wann sie behoben werden müssen. Lösungen, bei denen der Lieferant pro zu behebenden Fehler bezahlt wird oder bei denen nur Defects ab gewissen Prioritäten behandelt werden, sind meist sehr gefährlich. Dies schafft falsche Anreize.

Support

Vorteilhaft im Setup kann es zudem sein, wenn der externe Partner auch nach der Einführung des Projekts noch involviert bleibt. Z.B. für den Support oder zumindest für die Hyper-Care-Phase. So steigt sein Interesse an einer stabilen und möglichst fehlerfreien Lösung beträchtlich.

Beim Start der Zusammenarbeit

Eine enge Integration des Lieferanten in den Entwicklungs-, Defect- und Testprozess hilft. Die genaue Ausgestaltung ist jedoch stark abhängig vom konkreten Projekt-Setup und der gelebten Ausprägung der Agilität. In folgender Grafik aus dem SwissQ Agile Testing Framework sind eine Vielzahl der relevanten Themen ersichtlich:

Rhythmen

Idealerweise arbeitet der externe Partner in denselben Rhythmen (Sprints, Inkrements etc.) wie das Projekt. Sollte dies aus organisatorischen Gründen nicht möglich sein, dann sind die Übergabepunkte und jeweiligen Lieferobjekte vorgängig genau zu definieren.  Zudem muss darauf geachtet werden, dass möglichst jemand seitens Lieferanten bei den relevanten agilen Zeremonien (Daily, Refinement, Demo, Retro etc.) involviert ist.

Ziele

Zu Beginn oder in der frühen Phase der Realisierung ist es sehr empfehlenswert, Klarheit auf beiden Seiten zu verschaffen. Wenn z.B. der Lieferant sich als Ziel möglichst wenig Aufwand setzt (z.B. da Fix-Preis-Vertrag), während das Projekt maximale Qualität anstrebt, dann sind Folgeprobleme unausweichlich.

Inhaltliche Planung 

Auch die inhaltliche Planung der nächsten Sprints, Inkrementen oder Iterationen sollte möglichst in Absprache erfolgen, damit einerseits ein gemeinsames Ziel definiert wird, aber auch die unterschiedliche Ressourcensituation berücksichtigt werden kann. So sollten v.a. zu Beginn noch gewisse Reserven eingeplant werden, z.B. für Anpassungen oder sogar einen Probelauf, bis die Zusammenarbeit «eingeschliffen» ist.

Entwicklungs-, Test- und Kommunikationsplattformen 

Da eine Integration von externen Partnern vor Ort häufig nicht möglich ist, sollte unbedingt darauf geachtet werden, dass sie möglichst dieselben Entwicklungs-, Test- und Kommunikationsplattformen nutzen können, wie die internen Mitarbeiter. Z.B. Jira, Teams, WebEx, Zoom, Sharepoint, Testmanagement-Tool etc. Dies erfordert häufig einige Überzeugungsarbeit beim IT-Departement, damit Externe auf solche Systeme zugreifen können. Die Vorteile der engeren Zusammenarbeit ohne Medienbrüche überwiegen meines Erachtens jedoch deutlich. Falls unmöglich, dann sollte jeweils auf beiden Seiten ein Single Point of Contact definiert werden, der für die Abstimmung verantwortlich ist.

Testing-Aufgaben vom Lieferanten

Sofern nicht bereits vertraglich klar definiert, muss spätestens jetzt bestimmt werden, welche Testing-Aufgaben vom Lieferanten und welche vom Projekt übernommen werden. Dazu eignet sich z.B. die Test-Pyramide (siehe Grafik unten), der agile Testquadrant oder die Abbildung der gesamten Testingaktivitäten als Testing-Canvas. Alternativ kann auch das SwissQ-Testing-Periodensystem unterstützen. Dabei müssen die zur Verfügung stehenden Testumgebungen berücksichtigt werden, denn nicht jede Art von Test lässt sich in jedem System durchführen. Das Thema der Testdaten und Schnittstellen ist hierbei zusätzlich zu berücksichtigen.

Falls sich zeigen sollte, dass keine der beiden Seiten das notwendige Know-how oder die Ressourcen stellen kann, sollten zusätzliche externe Partner beigezogen werden, wie z.B. SwissQ.

Testautomatisierung

Sofern der Zulieferer seinerseits Testautomatisierung zur Qualitätssicherung einsetzt, sollte der Kunde klären, mit welcher Metrik die Qualität der Testautomatisierung beurteilt wird. Zudem sollte der Kunde prüfen, ob er an der Testautomatisierung partizipieren kann. Z.B. indem er diese Tests auf seiner Testumgebung mit realistischen Testdaten ausführt. Besonders interessant sind hier die Regressionstests, um die Grundfunktionalität des Produktes nach Änderungen sicherstellen zu können.

DoR & DoD

Bei der Festlegung der DoR (Definition of Ready) und vor allem DoD (Definition of Done) sollten auch die Bedürfnisse des Lieferanten einfliessen. Nur so kann danach deren Einhaltung seitens Lieferanten nachdrücklich einfordert werden.

Während des Projektes

Kulturelle Unterschiede

Je nach gewähltem externem Partner und Zusammenarbeitsmodell können kulturelle Unterschiede eine entscheidende Rolle spielen. Diese müssen z.B. mit einem Kick-off mit Kennenlern-Möglichkeit und einem offenen Austausch etc. angegangen werden.

Entwickler und Fachexperten

Ein direkter und möglichst ungezwungener Draht zwischen den (externen) Entwicklern und den internen Fachexperten ist zentral für eine agile Vorgehensweise. Auch ist es kritisch für den Projekterfolg. Das heisst die kommunikativen und organisatorischen Hürden sind für einen direkten Austausch möglichst tief zu halten. Die direkte Kommunikation (Meetings, Calls) ist z.B. gegenüber Ticketsystemen etc. zu priorisieren.

Abnahmekriterien

Bei der Erstellung der Beschriebe von Stories und vor allem deren Abnahmekriterien sollten immer Lieferant wie auch Kunde involviert sein. Dies da ein gemeinsames Verständnis zwingend ist. Über die Abnahmekriterien können Qualitätsansprüche definiert werden. Ein möglicher methodischer Ansatz ist hierzu das ATDD (Acceptance Test Driven Design, siehe Wikipedia) bzw. SwissQ Schulung Test Driven Development. Sollte eine direkte Zusammenarbeit unmöglich sein, so sind zumindest Review-Zyklen vorzusehen. Weitergehende Informationen hierzu gibts im Abnahmekriterien-Blog.

Abnahmetests

Ein wichtiger Entscheid, der in Absprache mit dem Lieferanten getroffen werden muss, ist die Umsetzung der Abnahmetests. Diese dienen der «finalen» Prüfung der im Vertrag genannten Lieferobjekte. Ist das eine Phase am Schluss des Projektes oder eines Inkrements? Oder kann das, wie empfohlen, «agiler» umgesetzt werden, d.h. fortlaufend z.B. innerhalb oder nachgelagert an jeden Sprint? Wer ist zu involvieren und welche Nachweispflichten ergeben sich allenfalls aufgrund von Policen oder Gesetzen? Wichtig bei der Umsetzung ist vor allem eine saubere Vorbereitung sowie die Klärung von Verantwortlichkeiten.

Retrospektiven

Vom agilen Mindset sollte aber unbedingt hinsichtlich der Retrospektiven profitiert werden. Auch von der damit verbundenen, fortlaufenden Verbesserung der Abläufe und der Zusammenarbeit. «Probieren geht über studieren», zumal jede Konstellation der Lieferanten-Zusammenarbeit einzigartig ist. So kann agiles «Ausprobieren» im Sinne von Measure – Learn durch Verbesserungsmassnahmen zu optimierten Abläufen führen.

Welche dieser Massnahmen sind in deinem Projekt sinnvoll und umsetzbar? Hast du in deinem Projekt erfolgreich weitere Massnahmen anwenden können?

Kernaussagen

Zurückkommend auf die ursprüngliche Frage, ob Lieferanten auch Qualität liefern können, sehen meine Erfahrungen wie folgt aus:

• Wenn der Lieferant früh und eng miteinbezogen wird, dann kann eine Zusammenarbeit sehr wohl gute Resultate auch hinsichtlich Qualität liefern.
• Das Thema des Einbezugs und der Zusammenarbeit mit dem Zulieferer benötigt schon ab der ersten «Projekt-Idee»Beachtung und entsprechende Massnahmen, allerspätestens jedoch bei der Auswahl des externen Partners.
• Die Verantwortung für gute Qualität liegt sowohl beim Lieferanten wie auch beim Kunden. 
• Der Hauptschlüssel für Qualität ist die konkrete Ausgestaltung der möglichst engen Zusammenarbeit. Mit klarer Verantwortung und definierten Übergängen.
• Die tatsächlich umzusetzenden Massnahmen sind sehr abhängig von der spezifischen Konstellation der Zusammenarbeit.
• Schuldzuweisungen führen nicht zu besserer Qualität, Verbesserungsmassnahmen schon.

Folgende Massnahmen zeigen den grössten positiven Impact bzw. die stärksten negativen Folgen bei mangelhafter Umsetzung:

• Auswahl eines externen Partners, dem Qualität wichtig ist und der über reife Test- und Entwicklungsprozesse verfügt.
• Vertragliche Abmachungen, die die Zusammenarbeit und Verantwortlichkeit auch im Bereich Testing klar definieren bzw. sogar honorieren.
• Beim Projektstart müssen sowohl der externe Dienstleister als auch der Kunde effiziente Prozesse und eine enge Zusammenarbeit zu leben beginnen.
• Im laufenden Projekt müssen beide Parteien im agilen Sinne nach Verbesserungen und Optimierungen des Testings streben, wie auch der Qualität des Testobjektes.

Beachte diese Punkte zum richtigen Zeitpunkt und setze sie sinnvoll um. Dann kann in Zusammenarbeit mit externen Dienstleistern qualitativ hochwertige Software in agilen Projekten entstehen! Happy Testing!

Hast du Fragen zum Thema? Spezielle Erfahrungen erlebt? Oder möchtest du mit einem Sparringspartner über die Herausforderungen in deinem Umfeld sprechen? Dann melde dich bei mir. Ich freue mich auf ein unverbindliches Gespräch.