Mehr Erfolg mit externen Teams – 7 Punkte, die ihr bei der Auswahl externer IT-Partner beachten solltet

Ist in eurer Firma schon mal der Satz gefallen „Alles, was man nicht selbst macht, wird nichts”? Damit seid ihr nicht alleine! Ob Startup, Mittelständler oder IT-Abteilung eines Konzerns – für viele ist das sogar der Leitspruch ihrer Entwicklungsarbeit. Das ist zumeist nicht unbegründet und basiert auf bisherigen Erfahrungen mit dem Einbinden von “Externen”.  

Was aber, wenn das Startup „zu erfolgreich” läuft und dringend neue Entwicklungen nachlegen muss? Wenn Mittelständler und Konzern ambitionierte Wachstumsziele haben oder Prozesse und Geschäftsbereiche weiter digitalisieren wollen? Dann wird es oft knapp mit der eigenen Mannschaft – und an das schnelle Aufstocken mit qualifiziertem Neu-Personal ist schon lange nicht mehr zu denken. 

In dieser Situation ist die einfachste Lösung, die Anzahl der Produkt-Teams durch einen externen Partner zu erhöhen. Diese Lösung hat einige Vorteile: 

• Die Teams des Partners sind schnell verfügbar. Eine interne Stelle zu besetzen, dauert in der Regel drei bis sechs Monate – ein komplettes internes Team aufzubauen, umso länger.
• Ein cross-funktionales Team nimmt euch echt Arbeit ab. Es ist eine verbreitete Praxis, für die Skalierung externe Einzelpersonen zu casten. Im Gegensatz zu kompletten cross-funktionalen Teams (aus verschiedenen Software-Entwicklern, Designern, Product Owner, Scrum Master etc.) müsst ihr diese Einzelpersonen aber eng koordinieren, was zusätzlichen Aufwand bedeutet. Außerdem haben sie zahlreiche Abhängigkeiten zu Design etc. in eurer Organisation, was die Geschwindigkeit ausbremst. Ein komplettes cross-funktionales Team kann viel mehr Geschwindigkeit erzeugen, weil es sich selbst organisiert und wenig Abhängigkeiten nach außen hat.

• Ein etabliertes Team arbeitet gut zusammen. Es braucht seine Zeit, bis ein frisch zusammengestelltes Team effektiv zusammenarbeiten kann (Phasen eines Teams nach Tuckman), speziell wenn es sich um ein Team aus Personen aus verschiedenen Unternehmenskulturen bzw. Freiberuflern handelt.

  

• Oft sind die Kosten ein Argument gegen externe Teams. Dabei sind externe Teams gar nicht so viel teurer als Interne. Viele rechnen oft nur die direkten Personalkosten ein. Um aber beide Ansätze wirklich vergleichen zu können, hilft eine Vollkostenrechnung, in der auch Kosten für die Verwaltung, das Büro etc. auf den einzelnen Mitarbeiter umgelegt werden. 
• Der ein oder andere wird jetzt einwenden, dass er in der Vergangenheit schlechte Erfahrungen damit gemacht hat, in dieser Situation ein externes Team an Bord zu holen. Und tatsächlich kann bei der Skalierung durch externe Teams einiges schief gehen. Wenn ein Unternehmen ein solches Team beauftragt, delegiert es einen Teil seiner Arbeit an dieses Team. Diese Delegation muss wie jede andere sauber aufgesetzt sein, damit Auftraggeber und Auftragnehmer gemeinsam erfolgreich sind. Dazu orientieren wir uns in diesem Artikel am Scrum Prozess.

Die gute Nachricht: Diese Vorteile sind tatsächlich realisierbar! Allerdings solltet ihr vorab prüfen, ob euer externer Partner bestimmte Rahmenbedingungen erfüllt. Dabei soll euch dieser Artikel helfen – ebenso wie eine praktische Checkliste mit allen relevanten Punkten für die Suche nach externen Partnern. 

1. Sind dem Team eure Ziele und Rahmenbedingungen klar?

Damit sind wir auch schon beim ersten Punkt, auf den ihr achten solltet. Ihr sucht einen Partner, der euch hilft, eure Ziele zu erreichen. Damit das gelingt, muss der Partner die Ziele aber auch kennen. Ihr solltet zu Beginn der Zusammenarbeit und zu wichtigen Meilensteinen mit dem Partner über eure Ziele sprechen bzw. sie gemeinsam erarbeiten: 

• Warum entwickelt ihr das Produkt bzw. führt ihr das Projekt durch? 
• Wie werdet ihr bestimmen, ob ihr erfolgreich seid? 
• Wer sind eure Kunden und was sind deren Bedürfnisse? 
• Welches wirtschaftliche Modell liegt hinter dem Projekt oder Produkt? 
• Gibt es gewisse Termine wie Messen oder durch neue Gesetze, die zwingend eingehalten werden müssen? 

Es bietet sich an, mindestens zu Beginn der Zusammenarbeit oder der Arbeit an einem neuen Produkt mit dem Partner sogenannte Product Vision Workshops oder Discovery Workshops durchzuführen. Im Rahmen dieser Workshops erarbeitet das gesamte Produkt-Team gemeinsam mit dem Kunden Antworten auf die obigen Fragen. Ihr solltet auf jeden Fall darauf achten, ob der Entwicklungspartner euch nach euren Zielen fragt.

Ihr könnt auch herausfinden, ob ein Partner in der Lage ist, sich in eure Lage zu versetzen und auf euer Ziel hinzuarbeiten. Bringt zu einem solchen Workshop euer Problem/eure Zielsetzung mit und bittet den Partner um Vorschläge, wie er es lösen bzw. erreichen würde. 

Darüber hinaus solltet ihr mindestens zum Auftakt über (technische) Rahmenbedingungen mit dem Team sprechen: 

• Sind sie frei in der Auswahl des Technologie-Stacks? 
• Welche Technologieentscheidungen müssen sie mit euch abstimmen? (Vorsicht: Wenn ihr sie hier zu stark einschränkt, habt ihr wieder keine Arbeitserleichterung) 
• Welche wirtschaftlichen Entscheidungen (z.B. über Betriebskosten oder den Einsatz von Managed Services) muss das Team mit euch abstimmen? Habt ihr bestimmte bevorzugte Provider (z.B. AWS)? 
• Müssen vorhandene Software-Systeme angebunden werden? 
• Welchen Schutzbedarf hat euer Produkt bzw. eure Anwendung (Stichwort „Security“)? 

Diese Punkte könnt ihr in einem separaten Workshop besprechen. Auf jeden Fall solltet ihr sie vor Beginn der Zusammenarbeit geklärt haben. 

2. Bekommt ihr Transparenz über den Fortschritt? 

Zum Auftakt einer Zusammenarbeit oder eines Meilensteins über die Ziele zu sprechen, ist ein guter Anfang. Das Bild muss aber kontinuierlich weiterentwickelt werden und dazu ist euer Feedback wichtig. Achtet darauf, dass es in ausreichendem Maße Gelegenheiten gibt, zu denen ihr gemeinsam mit dem Partner die Ziele und die gewählten Lösungen überprüfen könnt. Dazu sind die folgenden Fragen wichtig: 

• Wie lang sind die Sprints des Partners? Vor allem bei einer neuen Zusammenarbeit raten wir davon ab, Sprints länger als zwei Wochen zu planen. Eure Möglichkeiten, Feedback zu geben und die Richtung der Entwicklung zu beeinflussen, sind bei längeren Sprints deutlich begrenzter. Wenn euer Partner Sprint-Längen von über vier Wochen vorschlägt, solltet ihr auf jeden Fall hellhörig werden. Derart lange Iterationen haben nichts mehr mit der im Scrum Guide beschriebenen Idee von schnellem Feedback zu tun. 
• Finden die Sprint Reviews und Sprint Plannings regelmäßig statt? Wir haben auch schon von Situationen gehört, in denen es relativ lange Sprints (drei Wochen) gab und der Entwicklungspartner die Sprint-Termine dann noch regelmäßig ausfallen ließ (Stichwort „Headless Sprints“). Ihr solltet immer darauf achten, dass die Sprint-Termine regelmäßig stattfinden. 
• Ist dem Team wichtig, eine Ansprechperson zu haben? Wenn das Team des Entwicklungspartners effektiv mit euch zusammenarbeiten möchte, sollte ihnen wichtig sein, wer ihre Ansprechperson ist. Ganz konkret, um ihn oder sie z.B. zu den Sprint-Terminen einzuladen. Sollte das Team euch nicht nach einer Ansprechperson fragen, ist das meist ein schlechtes Zeichen. Ein gutes Zeichen ist, wenn das Team für die Ansprechperson eine bestimmte Verfügbarkeit einfordert – auch wenn es schwer für euch ist. Dann sind sie an einer echten Kollaboration mit euch interessiert. 
• Ermöglicht euch das Team eine einfache Teilnahme an Sprint-Terminen? Wenn das Team an eurem Feedback wirklich interessiert ist, wird es euch die Teilnahme an Sprint-Terminen so einfach wie möglich machen und nicht darauf bestehen, dass ihr zu ihnen kommt. Entweder laden sie euch zu einem Video-Meeting ein oder sie kommen auch ab und an bei euch im Büro vorbei. Außerdem sind Artefakte wie das Product Backlog und das Sprint Backlog so aufgesetzt, dass ihr sie einfach einsehen und vor allem verstehen könnt. Sollten sie in einem Jira des Partners versteckt sein, auf das ihr keinen Zugriff habt, ist das ein schlechtes Zeichen. 
• Nimmt das gesamte Team am Review teil? Damit euer Feedback beim Team ankommt, ist die effektivste Variante, alle Team-Mitglieder beim Sprint Review dabei zu haben. Ihr solltet nicht mit Stellvertretern sprechen, weil hier Stille-Post-Effekte eintreten und dieses Vorgehen niemals effektiv (Das ganze Team kennt euer Feedback, eure Gedanken und Diskussionen) und in den seltensten Fällen effizient (eine Person hört das Feedback und gibt es als Multiplikator weiter) ist. 

Wenn ihr mit dem Partner remote zusammenarbeitet, bietet es sich an, mindestens alle zwei Wochen Videokonferenzen durchzuführen. Im Rahmen dieser Termine könnt ihr dann ein kombiniertes Sprint Reviews und Planning abhalten. Die Teilnehmer sind mindestens die Ansprechperson auf eurer Seite und das komplette Team auf Seiten des Partners. Eure Ansprechperson kann selbstverständlich weitere Stakeholder in den Termin mitbringen. Ein kombinierter Termin hat den Charme, dass ihr euch nicht zwei Termine im Kalender blocken müsst. Außerdem handelt es sich beim Planning eher um eine Light-Variante: Der Partner macht einen Vorschlag für den nächsten Sprint und stimmt ihn mit euch ab.

3. Entstehen zu den Sprint Reviews wirklich auslieferbare Produktinkremente?

Jetzt kommen wir dazu, in welcher Form ihr den Fortschritt der Entwicklung in Augenschein nehmen könnt. Die Prinzipien des agilen Manifests sind in diesem Punkt sehr eindeutig: „Working software is the primary measure of progress“. Deswegen solltet ihr auf die folgenden Punkte achten: 

• Lasst euch lauffähige Produktversionen zeigen! Ein Sprint Review anhand von Power-Point-Folien hilft euch nicht einzuschätzen, ob hier das richtige Produkt entsteht. Vor allem wenn die Folien nur Statustexte und Ampeln enthalten. Seht euch in jedem Sprint Review den aktuellen Stand der Software an. Wenn der Partner wirklich an eurem Feedback interessiert ist, wird er selbst dafür sorgen. Selbst eine App lässt sich über den Simulator oder die Bildschirmfreigabe in einer Videokonferenz präsentieren. Lasst euch hier nicht mit Ausreden abspeisen. 
• Oder probiert sie am besten noch selbst aus! Noch besser, als sich den aktuellen Stand der Entwicklung zeigen zu lassen, ist, ihn selbst auszuprobieren. Wenn ihr mit dem Partner z.B. eine App entwickelt, lasst euch regelmäßig eine neue Testversion ausliefern und probiert sie auf Herz und Nieren aus. So ist es viel wahrscheinlicher, dass ihr Ecken und Kanten findet und fundiertes Feedback geben könnt. 
• Habt ihr echte Shippable Product Increments? Wenn ihr ein gutes Team bei eurem Entwicklungspartner habt, dann hat dieses Team ausreichendes Vertrauen in seinen Software-Entwicklungsprozess, um jede Version, die ihr bekommt, auch auf Produktion zu pushen. 
• Seht ihr regelmäßig, wo ihr bezogen auf eure Ziele steht? In einem iterativen Vorgehen ist es wichtig, nicht in den „vom Hölzchen aufs Stöckchen“-Modus zu geraten, sondern immer die Ziele im Auge zu behalten. Bringt euer Entwicklungspartner parallel zum aktuellen Software-Stand z.B. ein Release-Burnup-Diagramm und/oder Parking Lot Chart mit, das den Fortschritt im Verhältnis zum Release-Ziel beschreibt? Wenn nicht, fragt ihn danach. Das Non plus Ultra ist, wenn das Team ins Sprint Review Auswertungen aus Google Analytics o.ä. mitbringt, um zu demonstrieren, inwiefern die aktuelle Version auf eure Business-Ziele einzahlt. Dafür müsst ihr natürlich mindestens alle zwei Wochen auf Produktion pushen. 

Sprint Reviews sind dazu gedacht, Feedback anhand des konkreten Produkts zu geben bzw. Feedback sogar vom Markt einzuholen. Dafür sollte es zu jedem Review ein stabiles, auslieferbares Produkt geben, das euch sukzessive euren Zielen näherbringt.

4. Habt ihr einen Überblick über die Kosten?

Speziell wenn euer Partner nach Time & Material abrechnet, ist es wichtig, einen Überblick über die Kosten zu behalten. Sonst kommt es später zu bösen Überraschungen. Die folgenden Parameter solltet ihr im Auge behalten: 

• Wisst ihr, was ein Sprint kostet? 
• Werdet ihr regelmäßig informiert, welche Kosten die Entwicklung des aktuellen Releases bereits erzeugt hat? 
• Bekommt ihr einen ungefähren Eindruck, welche Kosten bis zur Fertigstellung des Releases noch entstehen werden? 
• Wenn ihr ein gewisses Budget festgelegt habt: Habt ihr eine Information darüber, wie viel dieses Budgets bereits aufgebraucht ist und welche Funktionalität mit dem restlichen Budget noch umgesetzt werden kann? 
• Gibt es Möglichkeiten für euch, das Engagement zu bestimmten Punkten zu beenden, wenn die Kosten für eine weitere Software-Entwicklung keinem passenden Wert für euch gegenüberstehen oder ihr mit der Arbeit des Partners unzufrieden seid? 

Euer Entwicklungspartner sollte entweder mit Budget-Burnup-Diagrammen oder mit einer Wasserlinie im Product Backlog arbeiten. Bei ersterem wird der Budget-Verbrauch relativ einfach prognostiziert. Die Wasserlinie im Backlog zeigt immer an, welcher Teil mit dem bisherigen Budget noch umgesetzt werden kann.

5. Bringt sich der Partner aktiv ins Sprint Planning ein?

Nachdem das Team im Sprint Review Feedback von euch eingesammelt hat, folgt das Planning für den folgenden Sprint. Wenn ihr an unterschiedlichen Orten arbeitet, kann es sinnvoll sein, beides in einem kombinierten Termin hintereinander durchzuführen. Dabei kann sich euer Partner entweder aktiv oder passiv verhalten: 

• Bekommt ihr Vorschläge fürs Planning? Wenn der Partner eure Ziele verstanden hat, wird er zum Planning einen Vorschlag für den nächsten Sprint mitbringen und mit euch besprechen. Sollte er einfach nur auf eure Anweisungen für den nächsten Sprint warten, ist das in der Regel ein schlechtes Zeichen. 
• Sind Diskussionen an euren Zielen ausgerichtet? Inhaltliche Diskussionen über die Ausgestaltung und Priorisierung von Features sollten sich an euren Zielen und nicht an persönlichen Geschmäckern ausrichten. Wenn in den Diskussionen immer wieder die Verbindung zu euren Zielen hergestellt wird, hat das Team sie verstanden und verinnerlicht. Menschlich ist aber, dass trotzdem mal ein Satz fällt wie: „Wenn es so und so wäre, würde ich es lieber benutzen“. 
• Schlägt euer Partner einfache, verständliche Lösungen vor? Gut ist, wenn das Team euch nicht mit Fachchinesisch einlullt, sondern versucht, euch Lösungen anschaulich zu beschreiben und nicht unnötig kompliziert zu machen. 
• Hilft das Team euch bei Priorisierungsentscheidungen? Es gibt zahlreiche Möglichkeiten, um Backlog Items zu priorisieren (Business Value, Cost of Delay, Risiko, Aufwand, …). Ihr müsst situativ die richtige auswählen und ein gutes Produkt-Team hilft euch dabei, indem es z.B. auch spontan mal den Aufwand einer Umsetzungsoption einschätzt. 

Ein gutes Sprint Planning ist oft wie eine Börse. Das Team schlägt euch etwas vor, ihr macht möglicherweise ein Gegenangebot („Mir wäre das Feature wichtiger, weil …“). Vielleicht ist dieses Feature aber zu groß. Das Team möchte dann verstehen, welchen Wert die Umsetzung in diesem Sprint hat, und macht euch ein Angebot, wie dieser Zweck möglicherweise mit geringerem Aufwand erreichbar ist. Nach einer gewissen Zeit ergibt sich aus Angebot und Nachfrage ein Scope für den folgenden Sprint. Damit das möglich ist, müssen beide Parteien ihre Hausaufgaben gemacht haben und das Produkt-Team eure Beweggründe verstehen wollen.

6. Ist das Team stabil? Habt ihr direkten Kontakt?

Im Optimalfall finden die oben genannten Diskussionen nicht nur im Sprint Review und im Sprint Planning, sondern kontinuierlich statt. Damit das funktioniert, sind ein paar Punkte wichtig: 

• Kennt ihr die Team-Mitglieder persönlich? Wichtig für die Kollaboration mit dem Kunden ist der direkte Draht. Ihr solltet euch nicht vorschreiben lassen, dass alle Kommunikation nur über den Projektleiter oder Product Owner des Teams stattfindet und alle Team-Mitglieder hermetisch abgeschirmt werden. Bindet den PL/PO aber bitte ein, damit er Bescheid weiß. 
• Ist das Team stabil? Sind im Team über einen längeren Zeitraum dieselben Mitglieder oder geht es eher zu wie auf der Durchgangsstation? Wenn die Mitglieder jede Woche wechseln, ist das ein schlechtes Zeichen. Auf der anderen Seite ist es auch nicht verkehrt, wenn gelegentlich mal ein wenig frischer Wind ins Team kommt. 
• Informiert euch der Partner über Veränderungen im Team? Es ist normal, dass ab und zu neue Mitglieder ins Team kommen oder andere ausscheiden. Informiert euer Partner euch darüber oder bekommt ihr es nur durch Zufall mit? 
• Gibt es Werkzeuge für Ad-Hoc-Kommunikation? Wie könnt ihr zu den Team-Mitgliedern Kontakt aufnehmen? Hier ist es sinnvoll, dass es mindestens einen E-Mail-Verteiler fürs Team gibt. Besser ist noch eine Lösung über ein modernes Group Chat Tool wie Slack oder Microsoft Teams. 

Stabile Teams, die aber „atmen“ können, sind der Schlüssel zum gemeinsamen Erfolg. Der Kunde hat direkten Zugang zu allen Mitgliedern des Teams und die Kommunikation läuft über Slack, Microsoft Teams, E-Mail oder Telefon. 

7. Denkt der Partner über das konkrete Projekt hinaus?

Wenn die Zusammenarbeit mit dem Team während der Entwicklung des Produkts oder Projekts gut funktioniert, stehen die Chancen gut, dass es sich um einen zukunftsorientierten, langfristigen Partner handelt. Er sollte mit euch in eurem Geschäftsmodell denken und sich die folgenden Fragen stellen: 

• Wie wird das Produkt einmal betrieben werden? 
• Wie stellen wir fest, ob das Produkt zum einen stabil und zum anderen erfolgreich ist? 
• Was sind passende Metriken für das Produkt? 
• Was ist nötig, dass euer Support, Sales und Marketing das Produkt sinnvoll betreuen können? Gibt es andere Anforderungen an die Production Readiness? 
• Bietet der Partner einen Betrieb für das Produkt an? 
• Wenn das Produkt nicht vom Partner weiterentwickelt und betrieben wird: Wie stellt er den Wissenstransfer sicher? 

Ein guter Partner spricht relativ früh und außerdem kontinuierlich mit euch über diese Fragen. 

Konkrete nächste Schritte

Wir bei cosee verfolgen getreu dem agilen Manifest die Maxime „Customer Collaboration over Contract Negotiation“. Uns ist eine vertrauensvolle Kollaboration wichtiger, als monatelang über jede Formulierung im Vertrag zu feilschen. Trotzdem gibt es einige Punkte, an denen ihr schon das Angebot eines potenziellen Partners prüfen könnt. Wir haben Sie für euch in einer Angebots-Checkliste zusammengefasst. Für die weitere Kollaboration gibt es ebenfalls Checklisten zum Download.

Download Checklisten

Wenn ihr Lust bekommen habt, die Kollaboration mit einem unserer Entwicklungs-Teams auszuprobieren, meldet euch gerne bei uns.

Kontakt aufnehmen