Ein erfolgreiches Entwicklungsteam aufbauen

Viele Startups müssen ein Entwicklungsteam aufbauen. Auch etablierte Hersteller stehen regelmäßig vor der Aufgabe, bestehende Entwicklungsteams zu erweitern, aufzuteilen oder neu auszurichten.

Dabei können sie von den Best Practices der Startups lernen und so die Produktivität ihres Entwicklungsteams, seine Effizienz und die Motivation der Teammitglieder erhöhen.

Einige dieser Best Practices stellt dieser Artikel übersichtlich und in sechs Schritten geordnet vor.

1. Schritt: Entscheiden, ob ein Entwicklungsteam benötigt wird

Manchmal ist dasjenige Entwicklerteam das beste, das man gar nicht hat. Als Faustformel kann gelten:

Wenn die Software den Kern des Angebots oder sogar das Produkt selbst darstellt, sollten Sie ein eigenes Software-Entwicklungsteam etablieren.

Falls hingegen die Software nur ein Hilfsmittel ist, um die Dienstleistung zu erbringen, können Sie Alternativen erwägen. Dazu zählen

• der Einsatz und die Anpassung bestehender Software-Lösungen sowie
• die Entwicklung durch einen spezialisierten Dienstleister.

2. Schritt: Den richtigen Zeitpunkt finden, um das Entwicklungsteam aufzubauen

a) Vorlauf von 3 bis 6 Monaten einplanen

Vom Zeitpunkt der Entscheidung für den Aufbau eines Entwicklungsteams bis zum produktiven Arbeiten vergehen durchschnittlich drei bis sechs Monate. Das setzt allerdings voraus, dass man weiß, wie man so ein Team aufbaut!

b) Notwendige Voraussetzungen schaffen

Sowohl Startups als auch etablierte Hersteller sollten erst mit dem Aufbau des Entwicklungsteams beginnen, wenn die folgenden Voraussetzungen erfüllt sind:

1. Produktvision ist geklärt
   Die Produktvision ist klar und hat einer ersten Bewertung durch potenzielle Kunden standgehalten.
2. Zweckbestimmung und Stakeholder-Anforderungen sind erhoben
   Die Zweckbestimmung sowie die Anforderungen der Stakeholder sind erhoben. Dazu zählen v. a. die Nutzungsanforderungen (User Requirements) und die fachlichen Anforderungen.
3. Product Owner ist etabliert
   Es gibt eine Person im Unternehmen, die z. B. als Product Owner die Produktvision und die Zweckbestimmung verinnerlicht hat. Diese Person steht sowohl während als auch nach dem Aufbau des Entwicklungsteams zur Verfügung.
4. Finanzielle Mittel sind vorhanden
   Das Unternehmen verfügt über die finanziellen Mittel, um ein Entwicklungsteam aufzubauen.
5. Form der Integration ist definiert
   Das Unternehmen hat eine Vorstellung, wie es sein Entwicklungsteam ins Unternehmen einbetten möchte. Dazu zählt z. B. die Entscheidung, ob es auf Präsenz der Entwickler:innen in eigenen Räumlichkeiten besteht und welche Erwartungen bei internationalen oder remote arbeitenden Mitgliedern bezüglich der Sprachkenntnisse oder der Zeitzonen bestehen.

3. Schritt: Entscheiden, wie das Team besetzt wird

a) Über Rollen entscheiden

Bereits die Festlegung, welche Rollen in einem Entwicklungsteam besetzt werden, entscheidet über die Kultur, die in diesem Team später herrschen wird.

Software-Architekt:in

Beispielsweise birgt die Entscheidung, einen dezidierten Software-Architekten bzw. eine Software-Architektin einzustellen, sowohl Chancen als auch Risiken:

• Chancen
  Die Wahrscheinlichkeit, dass eine gut dokumentierte, konsistente und einfach wartbare Software-Architektur entsteht, steigt, wenn es eine eigene Rolle dafür gibt.
  Dies Rolle hilft zu vermeiden, dass sich (wie sonst üblich) architektonische Schulden anhäufen, die nach wenigen Jahren aufwändig abgetragen werden müssen. Denn dann entstehen Phasen, in denen kaum neue Features entwickelt werden und somit Unzufriedenheit bei den Kunden entsteht.
  
• Risiken
  Genau dieses Bestehen auf integre Architekturen kann das Team in der frühen „Sturm- und Drangphase“ ausbremsen und den Zeitpunkt des „Product-Market-Fit“ hinausschieben. Dauert das zu lang, verhungert das Unternehmen.

Andererseits schafft es eine gute und effiziente Architekturerstellung, die Software ebenso gut und effizient und damit sogar schneller zu entwickeln. Diesen Umstand verstehen viele Senior-Entwickler besser als „Vollblut-Architekten“.

Wichtiger als die Frage nach der Rolle sind bewusste und korrekte Entscheidungen zur Software-Architektur. Im Idealfall können auch Senior-Entwickler diese Entscheidungen treffen. Der Verzicht auf eine dezidierte Person darf nicht mit dem Verzicht auf die Rolle verwechselt werden. Denn die Rolle ist notwendig, um den ganzen Prozess abzubilden.

Programmierer:innen

Dass das Entwicklungsteam leidenschaftliche Software-Entwickler und -Entwicklerinnen benötigt, ist offensichtlich.

Software-Tester:in, Mitarbeiter:in Qualitätssicherung

Weniger offensichtlich ist die Rolle, die für die Qualitätssicherung zuständig ist. Aber insbesondere bei Medical Startups ist sie unerlässlich.

Diesen Hut kann beispielsweise der bzw. die Software-Tester:in aufhaben. Es muss von Beginn an eine Person geben, die alle Aspekte der Software-Qualitätssicherung vorantreibt:

• Konstruktive Qualitätssicherung
  Dazu zählen Auswahl bzw. Gestaltung und kontinuierliche Verbesserung von Prozessen, Methoden (z. B. Modellierung, Testmethoden) und Werkzeugen.
  
• Analytische Qualitätssicherung
  Das Software-Testen, die Code Reviews und die statische Code-Analyse inklusive des Nachverfolgens von Code-Metriken und Kodier-Richtlinien sollten gleich zu Beginn etabliert werden. Eine nachträgliche Einführung erweist sich als schwierig und aufwändig.
  Die damit betraute Person sollte unbedingt darauf achten, den Automatisierungsgrad z. B. von Regressionstests und statischen Code-Analysen zu erhöhen. Denn das sind die Leitplanken bei der weiteren Entwicklung.

b) Über Senioritätsgrade entscheiden

Beim Aufbau des Entwicklungsteams gilt es, eine gute Balance bei den Senioritätsgraden zu behalten.

• Ist die Spreizung zu groß, entstehen Hierarchien, die für die Teambildung und für dessen Produktivität nachteilig sind.

• Baut man ausschließlich auf begeisterungsfähige Programmiereinsteiger, ist das gefährlich. Denn dann droht die Software-Qualität zum Problem zu werden.

4. Schritt: Die richtigen Personen für das Entwicklungsteam finden

a) Abhängigkeiten der Entscheidung für oder gegen globale Teams beachten

Die Entscheidung, wo das Team räumlich arbeiten soll und darf, wirkt sich auf das Recruiting aus:

• Der Pool möglicher Kandidat:innen ist global offensichtlich größer als lokal. Spätestens seit der Pandemie ist es sogar schwieriger geworden, Entwicklerinnen und Entwickler zu finden, die (regelmäßig) ins Büro kommen möchten.
  
• Die Kosten für Mitarbeitende sind in Ländern wie Deutschland, Österreich oder der Schweiz bedeutend höher als in anderen Ländern.
  
• Die Länge des Bewerbungsverfahrens spielt eine Rolle. International ist ein Verfahren, das mehr als zwei Wochen vom ersten Kontakt bis zum Vertragsangebot dauert, für viele Bewerberinnen und Bewerber zu lang. Sie haben dann längst ein alternatives Angebot gefunden.
  
• Ähnliches gilt für die Akzeptanz von Probearbeiten: Selbstverständlich sollten Sie die Fähigkeiten der Bewerberinnen und Bewerber prüfen. Aber mit Programmieraufgaben, die deutlich mehr als einen halben Tag in Anspruch nehmen, schrecken Sie Bewerber ab.
  
• Die Verträge (Arbeitsverträge, Dienstleistungsverträge) müssen so gestaltet sein, dass sie ohne Änderungen global gültig sind. Das betrifft nicht nur die Sprache.
  
• Abhängig vom geographischen Suchradius sind unterschiedliche Kanäle zur Ansprache potenzieller Bewerberinnen und Bewerber geeignet.

Je mehr potenzielle Kandidatinnen und Kandidaten von der Stelle erfahren, desto höher ist die Wahrscheinlichkeit, die richtige Person zu finden. Deshalb ist es hilfreich, über mehrere Kanäle zu suchen, beispielsweise:

• Klassische Job-Portale
• Suche und direkte Ansprache von Personen auf LinkedIn
• Analyse von Foren und Suche nach aktiven und relevanten Personen
• Suche auf Github und gezielte Ansprache von Kandidaten und Kandidatinnen. Nicht nur Open Source-Projekte mit relevanten Technologien eignen sich. In Ländern wie Brasilien gibt es sogar eigene Repositories, die als Jobmarkt fungieren.

b) Mission und Vision kommunizieren

Sobald eine geeignete Person gefunden ist, gilt es, gleich das Bewerbungsgespräch zu führen und dabei das Unternehmen und die Produktvision vorzustellen. Der Vorteil der Medizinbranche ist, dass sie einen Beitrag für die Patienten und das Gesundheitswesen leistet. Solch eine Mission ist für viele Entwicklerinnen und Entwickler von Bedeutung.

c) Sorgfältig auswählen

Wenn man einen Hammer hat, sieht alles wie ein Nagel aus. Trauen Sie sich, „polyglotte“ Entwickler:innen zu suchen. So schaffen Sie sich mehr Lösungsoptionen. Selbst wenn Ihre HR-Abteilung nicht technisch orientiert ist, kann sie nachfragen, was denn die Vorteile von Framework A und B (bspw. “Wie unterscheiden sich JavaScript und Python?” oder “Worin liegen die wesentliche Unterschiede von Angular und React.js?”), sind und wann der Kandidat welches empfehlen würde.

Suchen Sie qualitätsorientierte Entwickler:innen. Besonders im Web-Umfeld kann man viele Abkürzungen nehmen, die sich bei einem Medizinproduktehersteller später regulatorisch rächen könnten. Eine mögliche Frage im Interview wäre, wie der Entwickler dazu steht, selbst Tests zu schreiben.

5. Schritt: Ein gutes Onboarding bewerkstelligen

Die neuen Mitglieder des Entwicklungsteams müssen vom ersten Tag an wissen, was auf sie zukommt und was von ihnen erwartet wird. Dazu zählt die klare Kommunikation, wie wichtig das Qualitätsmanagement und die Dokumentation für die Konformität und den Erfolg des Produkts sind.

a) Bedeutung des QMS sofort klarstellen

Die neuen Teammitglieder müssen die Anforderungen sofort kennenlernen und im Entwicklungsprozess zeitnah Feedback erhalten, wie gut sie die Anforderungen erfüllen. Das betrifft die QM-Anforderungen ebenso wie die Anforderungen an das Produkt.

b) Selbstwirksamkeit ermöglichen

Kleine, begrenzte Aufgaben mit klaren Ergebnissen schaffen frühe Erfolgserlebnisse und mindern somit die Abbruchquote in den ersten Wochen.

c) Ziele verständlich kommunizieren

Personen, die noch keine Medizinprodukte entwickelt haben, ist oft unklar, wie sie die regulatorischen Anforderungen (siehe Punkt a)) erfüllen können. Hier helfen Beispiele und „Musterlösungen“ sowie schnelles Feedback.

6. Schritt: (Zusammen-)Arbeit des Entwicklungsteams kontinuierlich unterstützen

a) Arbeiten mit Prozessen und Verfahren

Der Sinn von Prozessen besteht darin, eine verlässliche Qualität sicherzustellen, die nicht von den Leistungen Einzelner abhängt. Vereinbarte und gelebte Prozesse und Verfahren sind die Voraussetzung für eine effektive und effiziente Zusammenarbeit.

Beispiele für solche Prozesse und Verfahren sind:

• Abstimmung mit dem Product Owner
  Das Entwicklungsteam benötigt eine klare Struktur für Input (v. a. Anforderungen) vom Product Owner und für Rückmeldungen, ob der Output den Anforderungen genügt. Viele Unternehmen nutzen dazu Scrum und arbeiten mit Sprintlängen zwischen zwei und vier Wochen.
  
• Entwicklung der Architektur
  Das Entwicklungsteam sollte selbst regeln, wer die Entwicklungsentscheidungen trifft, wann diese getroffen und wie diese dokumentiert werden. Transparente und kollaborative Entscheidungen steigern die Motivation.
  
• Code Reviews
  Besonders bei verteilt arbeitenden Entwicklungsteams tragen die Code-Reviews und Merge Requests entscheidend dazu bei, dass die Mitglieder schnelles Feedback erhalten sowie die Code-Basis in Gänze kennenlernen und damit die Software-Qualität verbessert wird.
  
• Kontinuierliche Verbesserung
  Die Retrospektive bei Scrum ist ein zentrales Mittel, um aus Fehlern zu lernen und Prozesse, Methoden und Werkzeuge kontinuierlich zu verbessern. Die Freiheit und die Verantwortung für diese kontinuierliche Verbesserung sollte beim Entwicklungsteam liegen.
  
• Software-Freigabe
  Den Prozess der Software-Freigabe sollte das Team nicht nur deshalb ernst nehmen, weil die IEC 62304 diese Freigabe fordert. Vielmehr ist das der „Moment of Truth“:
  Wird wirklich geprüft, ob alle Maßnahmen getroffen wurden, um die Software-Qualität sicherzustellen? Wird wirklich nur Software freigeben, die diese Qualität auch erfüllt – oder wird vielleicht dem Drängen eines Kunden oder Stakeholders nachgegeben?
  Wenn das Unternehmen hier nicht konsequent handelt, konterkariert es alle seine Aussagen zur Relevanz der Software-Qualität. Software-Entwickler spüren diese Diskrepanzen sofort.

b) Arbeiten mit Werkzeugen

Die besten Werkzeuge sind wertlos, wenn niemand damit arbeitet. Das passiert, wenn

• deren Gebrauchstauglichkeit schlecht und die Arbeit damit zu umständlich ist,
• die Tools keine Tätigkeit unterstützen, die die Entwickler tatsächlich durchführen,
• es keine Vorgaben gibt und jeder seinen eigenen Tool-Stack verwendet.

Entwicklungswerkzeuge

Es gibt keinen Mangel an Werkzeugen. Bewährt haben sich „all-in-one-Lösungen“ wie Gitlab, die notwendige Funktionalitäten integrieren wie

• Versions- und Konfigurationsmanagement,
• Verwalten von Merge Requests,
• Automatisierung (CI/CD),
• Issue Tracking,
• Dokumentation.

Auch Atlassian bietet eine leistungsfähige „Tool Chain“ an, die jedoch mit wachsender Teamgröße überproportional teuer wird.

Kommunikationswerkzeuge

Insbesondere bei remote arbeitenden Entwicklungsteams müssen die Werkzeuge neben der synchronen auch die asynchrone Kommunikation unterstützen.

Die Auswahl an Tools ist riesig: MS Teams, Rocket.Chat, Slack, IRC, Twist, Discord, aber auch z. B. Gitlab bieten die notwendigen Funktionalitäten und meist auch Integrationsmöglichkeiten für andere Werkzeuge.

b) Arbeiten mit (Kommunikations-)Regeln

Gute Kommunikationswerkzeuge garantieren noch keine gute Kommunikation im Entwicklungsteam. Daher benötigt das Team zusätzlich Regeln und Vereinbarungen:

• Reaktionszeiten
• Kommunikationskanäle
• cc-Policy
• Office Hours (ab und bis wann darf man kommunizieren bzw. Kommunikation ignorieren?)

7. Fazit und Zusammenfassung

Ein leistungsfähiges Entwicklungsteam aufzubauen, ist keine Rocket-Science. Aber es gibt unzählige Kleinigkeiten, die man beachten muss, um den Erfolg des Teams zu ermöglichen. Die sechs genannten Schritte helfen, viel davon richtig zu machen.

Diese Schritte sind nicht nur Startups dienlich, sondern auch großen und/oder etablierten Firmen, die die Leistungsfähigkeit ihrer Teams verbessern wollen.

---

Dieser Artikel basiert auf einem Podcast mit Martin Schulze und Christian Johner.

Martin Schulze ist Gründer und Inhaber der Firma slash-m. Er unterstützt insbesondere Startups dabei, leistungsfähige Entwicklungsteams zusammenzustellen und zu etablieren.

Das Johner Institut hat bereits Hunderte Startups erfolgreich durch die Zulassung von Medizinprodukten begleitet. Johner Medical tritt dabei als Inverkehrbringer für Startups auf, die noch nicht über ein zertifiziertes QM-System verfügen, und stellt den Firmen eine umfassende Tool-Landschaft bereit. Melden Sie sich hier, wenn Sie mehr erfahren wollen oder Unterstützung wünschen.