Blog

team-as-a-service

Waarom Team-as-a-Service als je je eigen software ontwikkelt?

Hugo
Hugo

In onze eerste blog over Team-as-a-Service (TaaS) las je dat we ons met ons 'Hire a Team'-concept met name richten op start-ups en scale-ups die tech first denken, hart hebben voor goede software en weten hoe het balletje rolt. Vaak zijn dit partijen die hun software grotendeels zelf ontwikkelen: het is immers de kern van wie ze zijn. Geen TaaS nodig, zou je denken. Toch kan het nuttig zijn om externe expertise in te roepen. We schetsen drie scenario’s: Scenario 1: technical debt wegwerken Als je als start-up of scale-up afhankelijk bent van de software die je ontwikkelt, is het opbouwen van technical debt een serieus risico. Echter: In de vroege start-up fase is snelheid de allesbepalende factor. Tot de product-market fit gevonden is wordt technical debt vaak (terecht) voor lief genomen. Ga je vervolgens je product en je team opschalen, dan gaat die bagage steeds zwaarder wegen. Maar technical debt of niet, als scale-up wil je vooruit: focussen op de doorontwikkeling van je product of dienst. Dan kan het een goed idee zijn om een TaaS in te schakelen om een problematisch component of service te vervangen. Zo blijf je zelf gefocust op doorontwikkeling en voorkom je in een vroeg stadium dat er legacy ontstaat. Scenario 2: groeistuipen opvangen en sneller opschalen Als start-up of scale-up kom je vroeg of laat een periode tegen waarin het development team "de business" niet kan bijhouden. Dat kan zijn omdat je team nog niet optimaal draait of omdat er simpelweg een grote piek is in de vraag. Dan kan het slim zijn om een extern team in te schakelen. Door voor een bepaalde periode een geoliede TaaS ernaast te zetten, ontlast je je eigen team en schep je ruimte om de problemen op te lossen. Door de teams nauw te laten samenwerken of zelfs een gemengd team te smeden, kan er ook overdracht van cultuur en best practices plaatsvinden. Van developers, naar developers. Scenario 3: een side-product of side-technologie Zeker voor start-ups, maar vaak ook voor scale-ups geldt dat het slim is om je altijd beperkte development capaciteit te richten op het business-kritieke deel van je software, terwijl je een TaaS inschakelt om een secundair onderdeel te verzorgen. Stel je bent een native app ontwikkelaar, die zijn geld verdient met een mooie app voor Android en een voor iOS, maar na verloop van tijd besluit om er ook een web interface naast te zetten. Dan biedt het inschakelen van een TaaS heel veel voordelen. Zo hoef je niet à la minute extra mensen aan te trekken of je native ontwikkelaars bij te scholen in web development. Je eigen ontwikkelaars behouden hun focus en kunnen - als dat gewenst - is na verloop van tijd bijgeschoold worden in de technieken die het TaaS gebruikt. Ook dwingt het inschakelen van een TaaS je om je architectuur nog meer los te koppelen. En dat is weer goed voor de onderhoudbaarheid van je software op de lange termijn. Met ons in gesprek? Weten of Team-as-a-service van Tweede golf in jouw situatie goed zou kunnen werken? Neem vrijblijvend contact op met Hugo of Erik. Meer weten over ons TaaS-concept, 'Hire a Team'? Klik hier of lees Wat kost een NL development team?.

Wat kost een NL development team?

Hugo
Hugo

Je ziet het de laatste tijd steeds vaker: tech bedrijven die bewust kiezen voor het inhuren van een Nederlands development team, omdat - laten we het neutraal stellen - de ervaringen met offshoring niet onverdeeld positief waren. Extern team vs. intern team De vraag wat een NL-team kost, laat zich beantwoorden door een simpel rekensommetje, wat we hieronder gaan maken. Maar daarmee is de vraag of dat duur is (de hamvraag natuurlijk), nog niet beantwoord. Dat wordt bepaald door de alternatieven. We zetten de uitkomst van de rekensom daarom af tegen de optie die overblijft als je eigen ontwikkelaars bomvol zitten, en je offshoring al hebt weggestreept: zelf extra ontwikkelaars aannemen, om toch dat ene belangrijke Project X toch van de grond te krijgen. Om een eerlijke vergelijking te maken kijken we naar het complete (kosten)plaatje en niet alleen naar inkoopkosten vs. loonkosten. We hanteren daarbij twee scenario's: een 'good case' scenario waarin het aannemen van eigen developers goed verloopt, en een 'bad case' scenario, waarin het smeden van een team vertraging oploopt. Het gemiddelde van die scenario's vergelijken we met de inzet van een Nederlands team as a service. Kosten Project X Als uitgangspunt nemen we een project uit onze eigen praktijk dat we recent hebben ingeschat op 3000 uur. Die omvang ligt mooi in onze comfort zone; we hebben meestal te maken met projecten die om 2 tot 3 FTE vragen. Huur je voor Project X een NL-team in, met een tarief van tussen de 80 en 100 euro per uur, dan kost dat dus tussen de 240 en 300k. Kies je voor een compact team bestaande uit 2 of 3 developers met een capaciteit van totaal 60 uur per week, dan zijn ze in iets minder dan een jaar klaar. Scenario 1: hiring like a pro In dit scenario gaan we ervan uit dat het aannemen van ontwikkelaars lekker soepel verloopt. Al na 2 maanden kan een junior developer starten. Nog eens 2 maanden later gaat een senior developer aan de slag, die gezien zijn ervaring snel thuis zal zijn in de materie. In het bijzonder nemen we aan dat: Beide developers 5 dagen per week werken, waarvan gemiddeld 4 dagen overblijven voor daadwerkelijke development werkzaamheden (vakanties, feestdagen, scholing, interne aangelegenheden etc) De junior developer begint met een halve dag effectieve development tijd, wat binnen een half jaar lineair oploopt naar 2.5 dag per week en vervolgens constant blijft. De senior developer begint met een hele dag effectieve development tijd, wat binnen zes maanden lineair oploopt naar 4 dagen per week en vervolgens constant blijft. We nemen aan dat de senior in de eerste maanden vooral bezig is met opbouwen van de stack en de tooling. En we rekenen met de volgende kosten: Recruitment kosten: 40k totaal voor interne en externe kosten, eenmalig Loonkosten developers: 120k per jaar (50k + 70k) Loonkosten faciliteren en begeleiden vanuit de organisatie: 20k per jaar Reken je dit door, dan zie je dat: De doorlooptijd ongeveer een jaar en 7 maanden is De totale kosten voor deze periode gelijk zijn aan ongeveer 240k Scenario 2: een onverwachte gebeurtenis Het vinden en behouden van ontwikkelaars verloopt echter niet altijd zo soepel als in scenario 1. Als voorbeeld van een 'bad case' scenario kijken we nu, onder dezelfde aannames als hiervoor, naar wat het effect is van het vertrek van de senior developer na een half jaar. We gaan er daarbij vanuit dat het opnieuw 4 maanden duurt om een senior developer te vinden, tegen dezelfde recruitment en loonkosten, die dezelfde inwerktijd nodig heeft. Om het gat op te vangen wordt voor die 4 maanden een freelancer ingevlogen om te voorkomen dat het project stil valt. Reken je dit door, dan zie je dat: De doorlooptijd van het project ongeveer een jaar en 10 maanden is. De totale kosten voor deze periode gelijk zijn aan ongeveer 320k. Conclusie Beide scenario's leveren voor Project X een kostenplaatje op dat heel vergelijkbaar is met de kosten van het inschakelen van een extern Nederlands team. Het ontloopt elkaar niet zo veel. Conclusie: voor projecten met een omvang van 2 of 3 FTE kost een extern NL-team nauwelijks meer en is het risico op vertraging kleiner én is de doorlooptijd korter, omdat je sneller op stoom bent. Natuurlijk komen er meer afwegingen en nuances kijken bij een keuze voor intern of extern. We hebben aannames gemaakt en er zijn lange termijn voor- en nadelen die we nu niet meewegen. Bovendien kan een 'hybride' scenario, waarbij je start met een extern team, de tijd neemt om een intern team op te starten en werkzaamheden langzaam overhevelt, ook een slimme keuze zijn. Wil je meer weten over de verschillende manieren waarop je onze "Hire a Team"-dienst zou kunnen inzetten? Neem vrijblijvend contact op met Hugo of Erik.

Technical debt? Doe de check!

Erik
Erik

Is jouw auto tiptop onderhouden of stel jij een reparatie liever uit? Dat laatste is een risico. De kans is groot dat je auto kuren krijgt. Van vreemde geluiden tot onderdelen die het spontaan begeven. De snelweg kan ineens een serieuze uitdaging zijn. Dat is met software niet anders. Nou ja, bijna. Door overhaast te releasen, onvoldoende zorg te besteden of geen tijd te nemen voor achterstallige reparaties, bouw je schuld op en gaat je software rammelen en de velocity omlaag. Doe de check! Als chief tech weet je natuurlijk best wat de risico’s zijn, maar technical debt op tijd signaleren blijft evengoed lastig. Wil je weten of je vandaag nog in actie moet komen? Gebruik onze handige checklist. Je developers durven delen van de code niet meer aan te raken. Deze zin komt je heel bekend voor: ‘Kunnen we geen workaround bedenken?’ Bij estimates van ogenschijnlijk kleine tweaks roepen je developers: ‘100 uur’. Meten is weten en harde cijfers zeggen alles, maar je gebruikt nog geen tech-debt-tool. Je business collega's vinden de developers extreem inflexibel. Je vraagt je developers of ze een rewrite een goed idee vinden. Je krijgt een staande ovatie. Heb je bij drie of meer punten een vinkje gezet? Dan is het misschien wel tijd voor die grote beurt of in elk geval een check-up. Start bijvoorbeeld hier thinkapps.com/blog/development/technical-debt-definition-importance/ of hier kellysutton.com/2017/10/24/quantifying-technical-debt.html of hier engineering.riotgames.com/news/taxonomy-tech-debt. Tweede golf verhuurt compacte web development teams. Meer weten? Check onze 'Hire A Team' pagina.

Waarom Team-as-a-Service zo populair is

Erik
Erik

Het is al zeven jaar geleden dat Marc Andreessen onderwees "Why software is eating the world". Als het toen al niet duidelijk was, dan is het dat nu wel: softwarereuzen knabbelen voortdurend aan traditionele branches en soms gaat het met een minder subtiel, hap-slik-weg. Als het niet Google, Facebook of Apple is, dan zijn het wel "kleine" broertjes zoals Netflix, Airbnb, Spotify of Uber. En als die het niet zijn, dan staan er nog tienduizenden tech start-ups klaar om de wereld beter te maken met een nieuw stukje software. "Every company needs to become a software company" Nou wordt - gelukkig - niet de wereld opgegeten, maar alleen die bedrijven die zich niet aanpassen aan de veranderde situatie. In de jaren na Andreessens publicatie werd de wat dreigend klinkende titel al snel omgevormd tot een praktisch advies: "Every company needs to become a software company". Klinkt spannend, maar wat betekent dat voor jouw bedrijf of organisatie? Hoe doe je dat? "Every company needs to become a software company". Oke, check. Dan doen we dat toch? Een kwestie van de juiste expertise binnenhalen en een goed team samenstellen. Uhm, nou, dat is niet zo makkelijk. Je loopt direct tegen het meest acute probleem aan: goede developers zijn nauwelijks te vinden. Wat te doen? Je kunt bij een detacheerder aankloppen, maar die doet wat hij of zij moet doen en loopt na afloop met de opgedane kennis weer de deur uit. Nog meer tijd en geld investeren in recruitment is een andere mogelijkheid. Maar in deze krappe markt is het de vraag wanneer je je team compleet hebt en je velocity op peil is. Team-as-a-Service We hebben steeds meer software nodig, developers zijn moeilijk te vinden en dan is ook nog de gewenste time-to-market (altijd...?) kort. Niet op te lossen? Daar biedt Team-as-a-service (TaaS) uitkomst: neem een stevige short-cut en huur direct een ingewerkt team in. Je haalt alle capaciteit, competenties en ervaring in één keer in huis. Van UX-er tot hardcore developer. De groeiende aantrekkingskracht van TaaS zie je ook terug in het aantal aanbieders. In twee jaar tijd is dat in Nederland van een enkeling naar tientallen gegaan. Vijf voordelen van TaaS Redenen waarom TaaS zo aantrekkelijk is: Het speelt in op de "as a service"-trend, het ontzorgt, je hebt altijd je development capaciteit beschikbaar Je raakt niet verstrikt in de werving en selectie of recruitment madness van de huidige arbeidsmarkt Je leverancier is voortdurend bezig met innovatie om zijn teams cutting-edge te laten zijn en blijven, want dat is hun brood, ook een zorg minder voor jou Development kent vele specialisaties; je kiest wat je nodig hebt en haalt in één keer de hele stack in huis Een ingewerkt team gaat vliegend van start en biedt meer continuïteit dan een verzameling freelancers of gedetacheerden Niet alleen maar voordelen Natuurlijk heeft TaaS ook nadelen. Hoe zorg je er bijvoorbeeld voor dat je grip houdt op een ingehuurd team? De meeste TaaS-aanbieders hanteren een vorm van scrum en bieden je dus grip door je eigen product owner op het team te zetten. De PO bewaakt toegevoegde waarde en stelt prioriteiten, scrum biedt een helder proces en duidelijke rollen. Een andere prangende vraag is vaak: hoe hou ik de kennis binnen mijn bedrijf? Aan die vraag - en andere aspecten van Team-as-a-Service - besteden we in een volgend artikel aandacht. Hire a team Bij Tweede golf ontwikkelden we onze eigen Team-as-a-Service-variant, die we 'Hire a team' doopten. We hebben een specifieke doelgroep: start-ups en scale-ups die tech-first denken, die hart hebben voor goede software en weten hoe het balletje rolt. Ook daarover vertellen we later meer. Nu al meer weten? Neem contact met ons op of check onze 'Hire A Team' pagina. In Waarom Team-as-a-Service als je je eigen software ontwikkelt? vertellen we in welke situaties we tech bedrijven kunnen bijstaan, als aanvulling of ondersteuning van eigen teams.

De ideale product owner: 5 tips

Hugo
Hugo

Bij Tweede golf werken onze development teams altijd nauw samen met een product owner van de klant. Hoe beter de samenwerking, hoe beter het resultaat. Waar zou de ideale product owner volgens ons aan moeten voldoen? Hieronder vijf tips voor de ideale PO m/v. 1. De PO is de koning(in) van de toegevoegde waarde De product owner 'owns value'. Hij of zij kan als geen ander inschatten wat de waarde is van een feature voor zijn of haar stakeholders. En wat waarde creëert op de lange termijn. Daarbij hoort ook goed kunnen prioriteren en nee kunnen zeggen tegen zaken die niet als waardevol worden beschouwd. 2. De PO kent zijn pappenheimers Een goede PO kent zijn of haar organisatie als de beste. Hij of zij voelt verwachtingen en mogelijke zorgen van de stakeholders goed aan en is in staat dit te managen en breed draagvlak te creëren. Door stakeholders te betrekken, goed te luisteren en bruggen te slaan waar nodig. 3. De PO houdt zich staande... ... terwijl er aan alle kanten aan hem of haar wordt getrokken. Het is een stevige persoonlijkheid die goed functioneert tussen stakeholders enerzijds en het development team anderzijds. Want laten we wel zijn: stakeholders staan soms op hun strepen en developers zijn vaak eigenwijs. 4. De PO is de aanvoerder van het team Uiteindelijk neemt de product owner de belangrijke beslissingen, maar als aanvoerder van het development team betrekt hij of zij daar altijd de teamleden bij. Na verloop van tijd raken developers en PO steeds beter op elkaar ingespeeld. Termen als ‘aan een half woord genoeg hebben’ en ‘het moet zijn alsof hij hier werkt’ horen daarbij. 5. De PO vindt software maken leuk Tuurlijk, het gaat de PO in de eerste plaats om het uiteindelijke product. Maar het maken zelf en het software proces boeit hem of haar ook. Nieuwe dingen leren en begrijpen wat de software beter maakt. Ruwe bolster met een klein nerd-hartje. Voldoe je hieraan, dan ben je onze droom PO. Nieuwsgierig geworden naar of we al eens met onze ideale product owner gewerkt hebben? Of wil je meer weten over het inhuren van een development team van Tweede golf? Check dan tweedegolf.nl/hire-a-team. Met ons concept ‘Hire a Team’ staan we direct klaar om aan de slag te gaan. Informeer eens naar onze mogelijkheden en daag ons uit!