Wie Sie den richtigen Software Developement Partner finden und was es braucht, damit die Zusammenarbeit klappt

Bei Objectbay hat man sich vor allem einem Thema verschrieben: Software. In agilen, selbstorganisierten Teams wird für Kunden das entwickelt, was man zur Differenzierung in heiß umkämpften Märkten braucht – Individualsoftware. Im Interview verraten uns Geschäftsführer Daniel Haslinger und VP Growth und Business Development Hannes Wambach welche Fragen man sich als CIO bei der Zusammenarbeit mit externen Softwarentwicklungs-Partnern stellen muss und wie die Zusammenarbeit klappt.

Welche Herausforderungen und Chancen bringt die Zusammenarbeit mit externen Softwareentwicklern dabei?

Die wesentlichen Chancen bei der Zusammenarbeit mit externen Softwareentwicklungs- Partnern liegen auf der Hand:

1. Schnellere Time-to-Market, sofern der potentielle Entwicklungspartner nach Best Practice ausgerichtet ist und bereits sämtliche Tools, Methoden, etc. etabliert sind. In solchen Fällen ist ein Onboarding eines Projektes innerhalb weniger Tage möglich. Der Aufbau eines internen Teams inkl. der notwendigen Infrastruktur und organisatorischer Rahmenbedingungen wird realistisch betrachtet mindestens 9 bis 12 Monate in Anspruch nehmen.
2. Kostenersparnis, da die Kosten für den Personalaufbau und den Aufbau einer modernen state-of-the-art Test- und Entwicklungsumgebung wegfallen
3. Laufender Know-how Transfer durch die Zusammenarbeit mit einem externen Expertenteam in Richtung eigenes Unternehmen.
4. Höhere Effektivität, wenn das externe Team bereits eingespielt ist und sich die einzelnen Entwickler nicht erst in einem Team “finden” müssen. Dieser Prozess dauert erfahrungsgemäß drei bis sechs Monate.
5. Technische und UX Excellence, weil diese nicht als verhandelbare Größen gelten und durch die Umsetzung einer Vielzahl von Projekten seitens eines externen Entwicklungspartners bereits nachhaltig etabliert sein sollten.
6. Experten im Bereich agiler Softwareentwicklung, da dies deren Kerngeschäft ist und daher davon ausgegangen werden kann (sollte allerdings im Einzelfall geprüft werden), dass die einschlägigen Methoden und Frameworks wie Scrum, Pair Programming, Extreme Programming, Test Driven Development, Domain Driven Design, etc. umfassend beherrscht werden und nicht erst erlernt werden müssen.
7. Laufende Lieferung und 100%-ige Transparenz durch eine entsprechende auf CI/CD ausgerichtete Test- und Entwicklungsumgebung.

Grundsätzlich gilt es aber, bei der Evaluierung bzw. Zusammenarbeit einige Punkte zu beachten. Insbesondere stellt sich die Frage, ob man einen Partner sucht, der einfach nur das Programmieren übernimmt oder ob eine langfristige Zusammenarbeit mit einem Digitalisierungspartner im Bereich Individualsoftware im Fokus steht, der den Kunden von der Idee zum fertigen Produkt inhaltlich wie technologisch begleitet und unterstützt.

Welche Möglichkeiten der Zusammenarbeit gibt es?

Wenn man sich dafür entscheidet, das Thema Softwareentwicklung outzusourcen, stehen grundsätzlich die folgenden 3 Optionen zur Verfügung: Einsatz von Freelancern, Offshore & Nearshore Entwicklung oder ein lokaler Partner im DACH Raum.

Der Einsatz von Freelancern ist ein durchaus probates Mittel, wenn es darum geht, kurzfristige Engpässe zu überbrücken. Auch für überschaubare, nicht zeitkritische Aufgaben eignet sich diese Option. Handelt es sich aber um größere, komplexere Softwareentwicklungsprojekte, die den Einsatz eines gesamten Teams erfordern, sollte man von dieser Alternative absehen.

Bei Offshore & Nearshore werden die Entwicklungstätigkeiten auf einem anderen Kontinent (z.B.: Indien) im Falle von Offshore und an das angrenzende Osteuropa im Falle von Nearshore aus der DACH Perspektive ausgelagert. Häufig wird dieses Modell dadurch ergänzt, dass ein Projektleiter eingesetzt wird, der die Koordination und Kommunikation zwischen dem Kunden und dem Entwicklungsteam übernimmt. Dieser soll etwaige Defizite hinsichtlich Sprache, Kultur, Zeitdifferenz, etc. ausgleichen. An die Grenzen stößt dieses Vorgehen insbesondere dann, wenn die Entwicklung nach agilen Methoden oder Scrum durchgeführt werden soll. Beispielsweise ist laut Scrum keine Projektleitung oder “Übersetzungsfunktion” zwischen dem Product Owner des Kunden und dem Scrum Umsetzungsteam vorgesehen.

In Scrum bilden der Product Owner und die Entwickler ein Team, das Ende zu Ende für das Produkt verantwortlich ist. Der Product Owner definiert in Abstimmung mit den Stakeholdern das “Was” und dessen Prioritäten, das Umsetzungsteam das “Wie”. Product Owner und Umsetzungsteam stehen im ständigen, oftmals täglichen Austausch. Scrum funktioniert nur durch ständige Kommunikation. Es ist nicht zweckmäßig, dass ein Entwickler als Sprachrohr mit dem Product Owner kommuniziert und der Rest des Teams im Nachgang über die Inhalte und Ergebnisse informiert wird. Das ist auch relevant, wenn Teile des Teams zum Beispiel Senior Entwickler sich in den Auftraggeberländern wie Deutschland, Österreich, oder der Schweiz aufhalten und der Rest des Teams remote arbeitet. Trotz Einsatz moderner Kommunikationstechnologien wie Video Conferencing hat die persönliche Präsenz immer noch zahlreiche Vorteile. Nach Scrum sollen daher alle Teammitglieder co-located sitzen.

Bei Offshore oder Nearshore geht man daher gewisse Kompromisse und Einschränkungen im Hinblick auf die Forderungen des Scrum Frameworks ein. Diese können im Einzelfall zu deutlichen Defiziten in Puncto Kosten, Komplexität, Kommunikation, Effektivität, Agilität, etc. nach sich ziehen.

Als weitere Variante steht der Einsatz eines langfristigen, in DACH angesiedelten Digitalisierungspartners im Bereich agiler Softwareentwicklung bzw. Individualsoftware zur Verfügung, der das Unternehmen von der Idee zum fertigen Produkt inhaltlich wie technologisch begleitet und unterstützt. Hier kommen Dienstleister in Frage, die einen wesentlichen Baustein der Digitalisierungsstrategie des Kunden übernehmen können. Also jene Anbieter von Softwareentwicklungsleistungen, die proaktiv mitgestalten und nicht “nur” als verlängerte Werkbank oder Ressourcenpool fungieren.

Welche Fragen sollte man sich stellen, bevor man sich für einen Sofwareentwicklungs-Partner entscheidet?

1. Ist der Dienstleister in der Lage, Ende zu Ende (von der Idee bis zum Betrieb) zu unterstützen?
2. Was ist das Selbstverständnis des Dienstleisters? Proaktiver Digitalisierungspartner oder klassischer Auftragnehmer?
3. Ist das Unternehmen in der Lage, Best Practices in puncto agiler Softwareentwicklung einzubringen?
4. Entwickelt der Dienstleister tatsächlich nach agilen Methoden z.B.: Scrum inkl. der definierten Artefakte und Events?
5. Sind alle Entwickler Scrum zertifiziert?
6. Sind die Teammitglieder T-shaped?
7. Ist das Team cross-funktional?
8. Arbeitet das Team ausschließlich bzw. zu 100% für diesen Kunden?
9. Welche Technologien bzw. Frameworks werden unterstützt?
10. Wird in Sprints von vier Wochen oder kürzer voll funktionsfähige Software geliefert (Stichwort: CI/CD)?
11. Steht eine vollautomatisierte Test- und Entwicklungsumgebung nach aktuellem Stand der Technik zur Verfügung?
12. Wie erfolgt das Wissensmanagement des Dienstleisters?
13. Bietet der Dienstleister 24×7 Transparenz hinsichtlich Entwicklungsfortschritt, Velocity, etc. (Stichwort: Live Coding)?
14. Welche Garantien bzw. Möglichkeiten zum Vertragsausstieg bietet der Dienstleister?
15. Hat der Softwareentwicklungs-Partner seine Organisation nach dem agilen Manifest ausgerichtet?
16. Wie hoch ist die Wiederbeauftragungs- und Empfehlungsrate der Kunden des Dienstleisters?
17. Soll ein langfristiger Entwicklungspartner im Sinne von “software development as a service” oder ein Anbieter für die Umsetzung ein konkreten Projekts evaluiert werden?

Die Auswahl des richtigen Partners macht sich an einer Vielzahl von Kriterien fest und bestimmt zentral die Qualität des zu entwickelnden digitalen Produktes oder Services. Wie in allen Dienstleistungssektoren sind hinsichtlich Seriosität, Qualität, Leistungsumfang und Kundenzufriedenheit auch im Bereich Softwareentwicklungs-Dienstleister deutliche Unterschiede bei den unterschiedlichen Anbietern gegeben. Häufig wird in der Praxis der Stundensatz für die Programmierleistung als überwiegendes Entscheidungskriterium bei der Auswahl eines Entwicklungspartners herangezogen, was aber komplett falsch ist, denn dieser gibt beispielsweise keinerlei Auskunft über die Qualität der Leistung (z.B.: Code Qualität) oder die Velocity des Teams.

Die Voraussetzungen, die der Kunde schaffen muss, um sinnvoll mit einem externen Entwicklungspartner zusammenarbeiten zu können, sind relativ überschaubar. Folgendes ist von seitens des Kunden notwendig: Einerseits muss zumindest Produktidee klar im Kopf sein. Andererseits, sollte es einen Experten auf Kundenseite geben, der die fachliche Domäne beherrscht und die Probleme des Anwenders bestmöglich kennt. Vorausgesetzt der potentielle Entwicklungspartner kann den Kunden mittels Ideation, Product Vision Board, Story Mapping oder anderer Techniken unterstützen, reicht dieses Ausgangsszenario aus.

Was sind die organisatorischen Voraussetzungen für die Zusammenarbeit zwischen IT, Kunden und Externen?

Die organisatorischen Voraussetzungen für die Zusammenarbeit im Bereich Softwareentwicklung hängen von einer Vielzahl von Parametern ab. Die Wesentlichen dabei sind folgende:

• Wie hoch ist der Reifegrad und wie umfassend sind die Erfahrungen des Kunden im Bereich (agiler) Softwareentwicklung?
• Bestehen bereits interne Softwareentwicklungsteams und ist eine Zusammenarbeit mit diesen im Zuge der Projektumsetzung mit den externen Teams geplant?
• Was sind die technologischen Rahmenbedingungen seitens des Kunden – z.B: Vorgaben im Bereich Technologie Stack, Security, etc.?
• Geht es um eine projektspezifische Zusammenarbeit oder eine langfristige Partnerschaft in Sinne von “software development as a service”?
• Sind bereits ein Product Backlog sowie UX/UI Richtlinien oder lediglich eine Produktidee vorhanden?
• Ist eine auf CI/CD ausgerichtete Test- und Entwicklungsinfrastruktur beim Kunden vorhanden und ist diese zu verwenden oder nicht?
• Soll der Produktivbetrieb durch den Kunden oder den Dienstleister erfolgen?

Welche Methoden haben sich dabei bewährt?

Hinsichtlich der passenden Projektmethode ist zuerst eine Einordnung des Projektes nach seiner Komplexität hilfreich. Abhängig davon ob es sich um eine simple, komplizierte, komplexe oder chaotische Problemstellung handelt, eignen sich klassische oder agile Projektansätze besser oder schlechter. Der klassische Projektansatz (Project Life Cycle, z.B.: Wasserfall) basiert auf einem phasenweisen Vorgehen und geht davon aus, dass das Ergebnis des Projektes in gewissem Umfang durchgängig und stabil planbar ist.

Agile Vorgehensweisen haben sich aus der Erkenntnis entwickelt, dass Produktentwicklungen aufgrund der Komplexität, der hohen Dynamik von Veränderungen der Anforderungen, Technologien, Marktbedingungen und des Umfeldes nicht mehr durchgängig planbar sind. Mit Hilfe agiler Methoden stehen insbesondere die Zielsetzungen Flexibilität und Anpassungsfähigkeit auf Veränderungen im Vordergrund, die die Dynamik der Umfeldfaktoren und die Komplexität von Software als den Normalfall annehmen, um durch entsprechende agile Techniken, Tools und Verfahren auf diese zu reagieren. Scrum hat sich als der de facto Standard im Bereich agiler Softwareentwicklung etabliert und setzt auf eine inkrementelle, iterative Produktentwicklung in festgelegten Zeitfenstern (Timeboxes, 2-4 Wochen Zeitabschnitte), Sprint genannt. Nach jedem Sprint ist ein weiteres Inkrement des Produkts entstanden; mit einem bestimmten Nutzen- und Geschäftswert. Das Product Backlog enthält alle Anforderungen, die jedoch im Zeitverlauf veränderlich sein können. Dies ermöglicht eine adaptive Anpassung der Produktentwicklung an neue Erkenntnisse und Rahmenbedingungen. Im Rahmen der Entwicklung ist eine permanente, interaktive und enge Zusammenarbeit zwischen Umsetzungsteam und Product Owner (Fachexperte) sowie mit den Stakeholdern erforderlich. Diese laufende Zusammenarbeit geht weit über das Maß hinaus, welche bei der Projektabwicklung nach klassischen Projektmethoden üblich ist.

Welche Rahmenbedingungen sollten berücksichtigt werden?

Der Fachbereich des Kunden stellt einen Product Owner, der als Fachexperte das “Was” definiert und neben den definierten Scrum Zeremonien (Planning, Daily Scrum, Review, Retro) täglich in einem gewissen Umfang für Fragen zur Verfügung steht. Er priorisiert unter Einbeziehung der Stakeholder die Items im Product Backlog, trägt dafür die Verantwortung und hat auch die organisatorische Autorität.

Die IT des Kunden gibt die entsprechenden IT Standards, Richtlinien und technologischen Rahmenbedingungen vor, insbesondere wenn die zu entwickelnde Lösung in die bestehende IT Infrastruktur des Kunden eingebunden werden soll.

Das externe Entwicklerteam setzt autonom im Sinne der Maximierung des Geschäftswertes für den Kunden das “Wie” um und hat dafür auch die entsprechenden technologischen und organisatorischen Kompetenzen. Es kooperiert dazu laufend bzw. täglich mit dem Product Owner des Kunden.

3 Tipps für die Zusammenarbeit von internen und externen Entwicklerteams

1. Neben den teaminternen Retrospektiven sollen regelmäßige teamübergreifende Retrospektiven, wo externe und interne Teams gemeinsam teilnehmen, durchgeführt werden. In diesen Retrospektiven können dann bewusst Themen bearbeitet werden, die die Zusammenarbeit von internen und externen Teams betreffen.
2. Organisation von internen und externen Teams in sogenannten Feature-Teams. Das bedeutet, dass jedes Team alleine im Stande ist, ein komplettes Feature Ihres Produkts Ende zu Ende zu entwickeln, ohne dabei eine Abhängigkeit zu einem anderen Team zu haben. Dies erfordert, dass sämtliche Fähigkeiten, die hierfür nötig sind, auch im Team vorhanden sind. Durch dieses Setup ergibt sich eine Vielzahl an Vorteilen:
   • Der Product Owner kann frei nach Geschäftswert priorisieren, ohne dabei auf die spezifischen Fähigkeiten der Teams Rücksicht nehmen zu müssen.
   • Bei einer Verringerung der Teams, können die restlichen Teams ohne Probleme weiterarbeiten.
   • Der Abstimmungsaufwand zwischen den Teams wird verschwindend gering.
3. Nutzung bzw. Definition einheitlicher teamübergreifender Qualitäts- und Coding Standards.