Ein ganzes Dev-Team mieten? Das kann doch nur schiefgehen!

Tuckmans vier Phasen eines Teams sind mittlerweile ein alter Hut und vielen bekannt. Und trotzdem wird dieses Wissen in der IT oft konsequent ignoriert. Braucht ein Unternehmen z. B. Hilfe bei der Software-Entwicklung, ist es gang und gäbe, einfach ein paar Entwickler "zusammenzucasten". Wäre es nicht viel schlauer, in diesem Fall einfach ein ganzes Team zu mieten?

Die gängigen Vorbehalte sind: "Die Externen verbrennen dann nur unkontrolliert Geld", "Die Software wird für den Kunden damit zur Blackbox" oder "Das kann dann später beim Kunden niemand warten".

Wir zeigen aus zwei Perspektiven (Kunde & Dienstleister), wie es trotzdem funktionieren kann und welche Methoden man in Hinblick auf Kollaboration und Transparenz beachten sollte.

Transcript

1. Das kann doch nur schiefgehen! Ein ganzes Dev-Team mieten?
2. Konrad Hosemann Sascha Wechsung Konstantin Diener
3. reverse.supply Enabling circular economy for fashion and outdoor brands
5. Wir bearbeiten pro Monat max. 60.000 Second-Hand Artikel für
6. In welcher Situation befand sich reverse.supply?
9. Was nun?
10. externe Leute casten Leute einstellen Acquhire
11. 1. schnell verfügbar 2. nimmt echt Arbeit ab 3. Alternative zu internen Kapazitäten 4. Ausbildung von internen Mitarbeitern Warum Team mieten?
12. An dieser Stelle kam cosee ins Spiel …
13. maßgeschneiderte Produktentwicklung
14. Produktentwicklung starten Produktentwicklung skalieren
15. Discovery- Phase Backlog Experten-Teams Abrechnungs- modelle Auslieferung in Sprints Soft ware- Releases
16. Worauf hat reverse.supply geachtet?
17. Gain Creators Pain Relievers Pains Gains Products & Services Customer Job(s) Value Proposition Customer Segment : Strategyzer AG The makers of Business Model Generation and Strategyzer The Value Proposition Canvas strategyzer.com
18. Ein Software- Produkt umgesetzt bekommen. Aktuell keine ausreichende interne Mannschaft vorhanden Es muss schnell gehen. Der erste Schuss muss sitzen. Ausbildung des internen Teams Sitzen in Deutschland und können "mal eben vorbeikommen". Teilen unser Mindset und versuchen nicht nur, Geld zu verdienen. Ihr wisst schon im Angebotsprozess klar, woran ihr seid. Miete eine Produktent wicklungs- Team Ihr bekommt einen ehrlichen Partner, der nicht nur "Entwickler- stunden" verkaufen will. Das Team entwickelt euer Produkt und bringt euer Team auch noch etwas bei. Der Partner bringt einen modernen Entwicklungs- prozess mit, bei dem sich euer Team inspirieren lassen kann. Ihr bekommt einen guten Stack für weitere Services bzw. Produkte. Ihr bekommt ein fest zugeordnetes, stabiles Team. Euer Partner versteht nicht nur Agile Software-, sondern auch Agile Produktentwicklung. Euer Partner hat feste Tech Stacks, die er wirklich beherrscht und kann nicht "für Geld alles", Es gibt ein klares Konzept, wie Produktentwicklung und Ausbildung parallel funktionieren. Der Partner versucht möglichst viele "neuralgische Punkte" im Vertriebsprozess oder am Anfang ehrlich zu klären. Es gibt ein etabliertes Vorgehen für eine sinnvolle (!) Übergabe an euer Team.
19. Dann ist ja alles gut, oder? 🤔
20. Ein Software- Produkt umgesetzt bekommen. Aktuell keine ausreichende interne Mannschaft vorhanden Es muss schnell gehen. Der erste Schuss muss sitzen. Ausbildung des internen Teams Blackbox (technisch): Das externe Team trifft wichtige Tech- Entscheidungen ohne uns. Intransparenz (inhaltlich): Wir haben keine Ahnung, wie das Team vorankommt ... Lösungen helfen dem Auftraggeber nicht: ... und ob etwas nützliches entsteht. Meine Leute lernen nichts von dem Team. Das Team hat keine Zeit für uns: ... weil es für mehrere Kunden arbeitet und die anderen wichtiger sind. Das Team wechselt ständig. PO/PM/PL als Gatekeeper: Probleme kommen nur durch stille Post zum Team Team arbeitet nur Tickets ab und will das Nutzerproblem gar nicht verstehen. Halten keinen Kontakt zur übrigen Organisation und insbesondere zu den anderen Entwicklern. Sitzen in Deutschland und können "mal eben vorbeikommen". Teilen unser Mindset und versuchen nicht nur, Geld zu verdienen. Ihr wisst schon im Angebotsprozess klar, woran ihr seid. Miete eine Produktent wicklungs- Team Ihr bekommt einen ehrlichen Partner, der nicht nur "Entwickler- stunden" verkaufen will. Das Team entwickelt euer Produkt und bringt euer Team auch noch etwas bei. Der Partner bringt einen modernen Entwicklungs- prozess mit, bei dem sich euer Team inspirieren lassen kann. Ihr bekommt einen guten Stack für weitere Services bzw. Produkte. Ihr bekommt ein fest zugeordnetes, stabiles Team. Euer Partner versteht nicht nur Agile Software-, sondern auch Agile Produktentwicklung. Euer Partner hat feste Tech Stacks, die er wirklich beherrscht und kann nicht "für Geld alles", Es gibt ein klares Konzept, wie Produktentwicklung und Ausbildung parallel funktionieren. Der Partner versucht möglichst viele "neuralgische Punkte" im Vertriebsprozess oder am Anfang ehrlich zu klären. Es gibt ein etabliertes Vorgehen für eine sinnvolle (!) Übergabe an euer Team. intensive Tech- Diskussion zu beginn Klarheit: Welche Entscheidungen dürfen wir selbst treffen? => und in ADRs dokumentiert CTO in Dailys dabei interne Entwickler in alles eingebunden Stichproben- Code- Reviews: "Wie sieht das jetzt konkret aus?" Team konnte auf Augenhöhe mit dem CTO diskutieren. Große technische Schnittmengen und gleiches Verständnis von "Wie arbeitet man?" XYZ kann ich bauen, da weiß ich, dass es funktioniert. => Nicht alles geht immer und ist kein Problem. (nicht mit Blendern arbeiten) Product Vision im Kick- Off ausgefüllt. PO des DLs in Product Weeklys dabei. offene Reviews Alignment => Es muss für den Nutzer funktionieren. Inhaltlich richtig und nutzerfreundlich ist wichtiger als transparent. Wir waren uns einig, für wen was transparent sein muss. Mindestens eine inhaltliche Eskalation => Ist das im Sinne der Organisation? "gestaffelte Transparenz" PO des DLs in Product Weeklys dabei. gemeinsame Sprint Plannings mit dem Kunden Kick- Off vor Ort Teilnahme des Kunden und des kompletten Teams an Reviews. Gemeinsames Slack Team und viel Pairing klar festgelegte Prio auf "Wert schaffen" trotzdem viele Pair- Programming- Formate "even over"- Aussage technische Reviews der beiden Teams erster Teil des Plannings gemeinsam Team und Nutzer haben zusammen das Problem gelöst. Nutzer waren sehr zufrieden mit dieser Art der Arbeit. festes, stabiles Team Team fest zugeordnet
21. Ein Software- Produkt umgesetzt bekommen. Es muss schnell gehen. Der erste Schuss muss sitzen. Ausbildung des internen Teams Blackbox (technisch): Das externe Team trifft wichtige Tech- Entscheidungen ohne uns. Intransparenz (inhaltlich): Wir haben keine Ahnung, wie das Team vorankommt ... Lösungen helfen dem Auftraggeber nicht: ... und ob etwas nützliches entsteht. Meine Leute lernen nichts von dem Team. Das Team hat keine Zeit für uns: ... weil es für mehrere Kunden arbeitet und die anderen wichtiger sind. Das Team wechselt ständig. PO/PM/PL als Gatekeeper: Probleme kommen nur durch stille Post zum Team Team arbeitet nur Tickets ab und will das Nutzerproblem gar nicht verstehen. Halten keinen Kontakt zur übrigen Organisation und insbesondere zu den anderen Entwicklern. bzw. Produkte. Ls ct gemeinsame Sprint Plannings mit dem Kunden Off Ort Teilnahme des Kunden und des kompletten Teams an Reviews. Gemeinsames Slack Team und viel Pairing klar tgelegte auf "Wert haffen" m viele - ming- ate "even over"- Aussage sche ews iden ms erster Teil des Plannings gemeinsam
22. Ein Software- Produkt umgesetzt bekommen. Ausb d inte Te Blackbox (technisch): Das externe Team trifft wichtige Tech- Entscheidungen ohne uns. Intransparenz (inhaltlich): Wir haben keine Ahnung, wie das Team vorankommt ... Lösungen helfen dem Auftraggeber nicht: ... und ob etwas nützliches entsteht. Meine Leute lernen nichts von dem Team. Das Team hat keine Zeit für uns: ... weil es für mehrere Kunden arbeitet und die anderen wichtiger sind. Das Team wechselt ständig. PO/PM/PL als Gatekeeper: Probleme kommen nur durch stille Post zum Team Team arbeitet nur Tickets ab und will das Nutzerproblem gar nicht verstehen. Halten keinen Kontakt zur übrigen Organisation und insbesondere zu den anderen Entwicklern. entwickelt euer Produkt und bringt euer Team auch noch etwas bei. Ihr bekommt einen guten Stack für weitere Services bzw. Produkte. ehrlich zu klären. Team. intensive Tech- Diskussion zu beginn Klarheit: Welche Entscheidungen dürfen wir selbst treffen? => und in ADRs dokumentiert CTO in Dailys dabei interne Entwickler in alles eingebunden Stichproben- Code- Reviews: "Wie sieht das jetzt konkret aus?" Team konnte auf Augenhöhe mit dem CTO diskutieren. Große technische Schnittmengen und gleiches Verständnis von "Wie arbeitet man?" XYZ kann ich bauen, da weiß ich, dass es funktioniert. => Nicht alles geht immer und ist kein Problem. (nicht mit Blendern arbeiten) Product Vision im Kick- Off ausgefüllt. PO des DLs in Product Weeklys dabei. offene Reviews Alignment => Es muss für den Nutzer funktionieren. Inhaltlich richtig und nutzerfreundlich ist wichtiger als transparent. Wir waren uns einig, für wen was transparent sein muss. Mindestens eine inhaltliche Eskalation => Ist das im Sinne der Organisation? "gestaffelte Transparenz" PO des DLs in Product Weeklys dabei. gemeinsame Sprint Plannings mit dem Kunden Kick- Off vor Ort Teilnahme des Kunden und des kompletten Teams an Reviews. Gemeinsames Slack Team und viel Pairing klar festgelegte Prio auf "Wert schaffen" trotzdem viele Pair- Programming- Formate "even over"- Aussage technische Reviews der beiden Teams erster Teil des Plannings gemeinsam Team und Nutzer haben zusammen das Problem gelöst. Nutzer waren sehr zufrieden mit dieser Art der Arbeit. festes, stabiles Team Team fest zugeordnet
23. Muster
24. 🧨 technisches Alignment
26. • Legt klar die Rahmenbedingungen fest, nnerhalb derer sich der Dienstleister bewegen kann • Scha ff t technische Austauschformate zwischen den Teams (z.B. CoP) • Räumt Raum ein, damit die Teams sich kennenlernen.
27. 🧨 Problem Solution Fit
30. • Legt am Anfang klar das Ziel der Zusammenarbeit fest. • Macht klar, wo die Grenzen der Selbstorganisation sind. • Macht gemeinsame Reviews & Plannings und das regelmäßig. • Involviert echte Kunden/ Stakeholder in Reviews. • Legt fest, was und für wen transparent sein muss.
31. 🧨 Kollaboration & Interaktion
35. • Vernetzt die Teams miteinander. • Macht klar, was Vorrang hat (Helfen oder Produkt entwickeln) • Versetzt das externe Team in die Lage, selbst Entscheidungen zu tre ff en (Was brauchen die dafür?)
36. 🧨 Mitdenken
38. • Was ist das Ziel, das ihr erreichen wollt? • Gebt nur das Was vor, aber nicht das Wie. • Wie bestellt: Wenn ihr Dienstleistern eine Menge an Tickets gebt, arbeiten viele auch diese Tickets ab.
39. 🧨 Kontinuität
41. • Bekennt euch auch als Au ft raggeber zu einem festen, stabilen Team.
42. und Ausbildung parallel funktionieren. intensive Tech- Diskussion zu Beginn Welche Entscheidungen trifft Dienstleister selbst? Und dann trifft er sie auch selbst! CTO in Dailys dabei interne Entwickler in alles eingebunden Stichproben- Code- Reviews: "Wie sieht das jetzt konkret aus?" Team konnte auf Augenhöhe mit dem CTO diskutieren. Große technische Schnittmengen und gleiches Verständnis von "Wie arbeitet man?" PO des DL in Product Weeklys des AG dabei Reviews mit Nutzer (vom AG) Alignment => Es muss für den Nutzer funktionieren. Inhaltlich richtig und nutzerfreundlich ist wichtiger als transparent. Wir waren uns einig, für wen was transparent sein muss. Mindestens eine inhaltliche Eskalation => Ist das im Sinne der Organisation? "gestaffelte Transparenz" gemeinsame Sprint Plannings mit dem Kunden Teilnahme des Kunden und des kompletten Teams an Reviews. Gemeinsames Slack Team und viel Pairing klar festgelegte Prio auf "Wert schaffen" viele Pair- Programming- Formate "even over"- Aussage technische Reviews der beiden Teams erster Teil des Plannings gemeinsam Team und Nutzer haben zusammen das Problem gelöst. Nutzer kannten den Prozess und konnten ihn beeinflussen festes, stabiles Team Team fest zugeordnet Kick- Off vor Ort Product Vision im Kick- Off ausgefüllt. Alignment & Nähe technische Exzellenz Problem Solution Fit Kontinuität
43. Autonomie Alignment technische
44. Aber was passiert, wenn die Beziehung mal zu Ende geht?
45. Embedding Collaboration Inspired by devopstopologies.com
47. 1. Legt gemeinsam zu Beginn das inhaltliche Ziel und die technischen Rahmenbedingungen fest. 2. Findet heraus, was das Team für selbstständiges Arbeiten mit wenigen Abhängigkeiten braucht. 3. Aber definiert auch die Grenzen der Selbstorganisation. 4. Gewöhnt euch an ein festes, stabiles Team. 5. Checkt, ob der Dienstleister bestimmte Tech Stacks beherrscht (nicht alles). 6. Achtet darauf, ob die wichtigen Punkte im Vertriebsprozess zur Sprache kommen. Spickzettel (vorher)
48. 1. Macht gemeinsame Reviews und Plannings. Ladet echte Kunden/ Stakeholder zu den Reviews ein. 2. Priorisiert Bauen und Ausbilden. 3. Scha ff t Raum und Zeit für Austausch und Kennenlernen mit den anderen Teams. 4. Denkt schon ans Ende: Wie stellt der Dienstleister die Übergabe sicher? Spickzettel (dann)
50. Ihr wart die besten Adoptiveltern, die ich mir vorstellen konnte. Entwickler bei reverse.supply
51. talks.cosee.biz
52. Fragen zum Vortrag?