Het Project Startup Hackathon

Je start een nieuw project om systeem X te bouwen. Je gaat dat project 100% agile doen. Dat houdt in

  • niet vergaderen
  • multidisciplinair team met ook gebruikers, klanten, etc
  • continuous delivery
  • het team is in charge
  • het team heeft mandaat

Je begint dus met een kick-off meeting met alle betrokkenen en je trekt daar een ochtend voor uit. Na die kick-off meeting gaan de teamleden aan de slag, ze plannen vergaderingen, ze trekken zich terug in hun ivoren torentje, ze gaan verder met hun dagelijks werk dat niet kan blijven liggen, ze plannen “contactmomenten”. En voordat er ook maar iets is geproduceerd, heb je 80 mens-uur verspijkerd aan je project. Dat kan ook anders.

Als je wilt dat mensen in hecht verband samenwerken, moet je ze dat vanaf het begin van het project laten doen. Als je zo snel mogelijk precies wilt weten wat er hoe wanneer gemaakt moet worden, moet je ze gelijk laten beginnen met bouwen. Een vliegende start van je project bereik je met een Project Startup Hackathon. En dat werkt als volgt.

Je zorgt voor een projectruimte voor een dag waar alle betrokkenen in passen. Je nodigt alle betrokkenen voor die dag uit:

  • gebruikers
  • klanten
  • ontwerpers
  • programmeurs
  • beheerders
  • een manager
  • een verkoper
  • een boekhouder
  • etc.

Je zorgt voor alle tools en voorwaarden die nodig zijn:

  • servers of cloud of zoiets
  • laptops, computers, telefoons
  • een netwerk, internet
  • git, jenkins, etc
  • whiteboards, monitors, etc
  • lunch
  • diner (beter geen pizza)

Om negen uur ‘s morgens sta je midden in de ruimte, iedereen heeft een werkplek of soort van werkplek, en zit op een stoel. En je zegt

“Wij zijn het team dat product X gaat maken. Als begin gaan we vandaag een werkende versie van product X maken. Een proof of concept. Ik laat aan jullie over wat dat is, welke aspecten van product X dat dan behelst. Maar om zes uur vanmiddag wil ik een demonstratie zien van iets wat werkt. Als je daarvoor iets nodig hebt, dan zorg ik daar onmiddellijk voor.”

Als dit je eerste Project Startup Hackathon is, dan heb je natuurlijk wel nagedacht welke mensen je erbij vraagt. Omdat er geen projectleider of team lead is, heb je een aantal mensen nodig die die rol vanzelf op zich nemen. Die durven roepen “jongens, niet discussiëren, als Rajesh zegt dat we het zo gaan doen, dan gaan we het zo doen”. Mensen met de diverse benodigde expertise, mensen die het vertrouwen van anderen hebben dat wat ze zeggen ook wel klopt. Immers, als je maar een dag hebt om iets op te leveren ga je geen tijd verspillen aan subtiele discussies of aan ruzies.

Je gaat er zelf niet de hele tijd bij zitten want je wil geen nodeloze sturing geven. Je bent bereikbaar om alles te regelen wat ze nodig hebben, zoals koffie, computers, tafels, lunch, mensen, de kat van de buren, of wat dan ook. Wat je hoopt dat die dag gebeurt is het volgende.

De aanwezige klanten (of gebruikers) vertellen kort wat product X moet behelzen. Er is vraag en antwoord. Ontwerpers vragen naar het hoe en wat. Programmeurs vallen in met specifieke vragen vanuit de techniek. Een systeembeheerder bemoeit zich ermee naar aanleiding van opmerkingen van programmeurs. De verkoper stuurt de discussie bij, met “dat kun je niet verkopen, maar als je het zus en zo doet wel” en de boekhouder maakt de groep attent op wat op termijn veel kost en wat niet. Of zoiets. Een programmeur roept “laten we beginnen”. Gebruikers/klanten en designers gaan paarsgewijs aan het werk, programmeurs beginnen met de plumbing van de applicatie, de systeempersoon (de “op” van de devops) maakt een git/jenkins/etc instance werkend. Dan implementeren de programmeurs stukjes van wat de ontwerpers inmiddels hebben gemaakt, de klant/gebruiker kijkt mee en becommentarieert. Gewoon, zoals het in een hackathon gaat.

Je doel met deze hackaton is niet het proof of concept product per se. Het doel is in het team duidelijk te laten worden wat er gemaakt moet worden. Het doel is ook het team effectief te laten samenwerken en al werkend te laten kennismaken. In de loop van de dag zitten alle betrokkenen samen te “hacken” aan het proof of concept waarbij ze (hopelijk) op een zeer directe manier met elkaar communiceren en elkaar leren kennen en waarderen. Tegelijkertijd, tijdens dat hacken en de discussies waarmee het gepaard gaat, krijgen ze samen een goed beeld van wat er in het uiteindelijke product X moet zitten. De ontwerper weet hoe dat ontworpen moet worden, de programmeur weet hoe het geprogrammeerd moet worden, de op weet welke infrastructuur nodig is, de klant/gebruiker heeft na deze dag de directe communicatie met de rest van het team en kan dus van dag tot dag meekijken, meehacken en invloed uitoefenen.

Als het allemaal gaat zoals we denken dat het zal gaan, dan is deze hackathon ook de eerste dag van je project en gaat eigenlijk het project gewoon verder als “extended hackathon”. Je team blijft in de hackathon-ruimte zitten (daar had je van te voren natuurlijk al rekening mee gehouden), ze blijven samen verantwoordelijk voor het hele project, jij blijft beschikbaar om te zorgen voor wat ze ook dan maar nodig hebben, en de snelheid blijft in het project.

Als je een volgend project een vliegende start wil geven met een Project Startup Hackathon, dan haal je een paar mensen uit je eerste team voor het nieuwe project. Dat nieuwe project krijgt dan een vlotte start, nog vlotter dan het eerste, en in je eerste project krijgen nieuwe (wellicht meer junior) mensen de kans hun eigen vliegende start te maken.

Moet zo’n Project Hackathon team Scrum gebruiken? Laat me het zo zeggen. Een user story is in het hackathon project datgene wat gebruiker A of klant B zegt en wat gelijk gebouwd wordt en gedeployed. De sprints zijn variabel, dat zijn de perioden tussen release N en release N+1 zoals de devs en de ops dat van moment tot moment deployen. Dat hoeft niet gepland te worden: iemand zegt “we doen nu een deployment” en als een programmeur zojuist iets heeft opgeleverd en gemerged, dan zit dat erbij. Een andere programmeur is nog bezig met een paar features, en die zitten morgen in de deploy, of volgende week, of volgende maand. Moet je daily standups doen? Nou, de hele dag werkt als een daily standup. Je zit immers de hele dag bij elkaar aan tafel samen te hacken en dingen te ontwerpen en overleggen. Heb je iets van Safea nodig, dan wacht je niet tot morgen negen uur, maar vraag je het haar nu gelijk. Dirk hoort het je vragen, en doet een suggestie aan jullie beiden, of doet zijn voordeel met wat hij zojuist hoort.

Eén ding is super belangrijk in een Project Startup Hackathon, en in een hackathon in het algemeen. De mensen in je team zijn allemaal verschillend. Niet alleen qua expertise en ervaring, maar ook als mens. De ene is extrovert en begint gelijk te praten, de ander is wat terughoudender. De ene neemt gelijk de leiding, de ander kijkt eerst de kat uit de boom. De ene werkt het liefst alleen met tools en frameworks die hij of zij goed kent, de ander heeft voor je het weet iets geheel nieuws geïnstalleerd en gaat daarmee aan de slag. Wat je dus nodig hebt is een wederzijds begrip en waardering tussen al die mensen. De extrovert moet aan de introvert vragen “hey, wat vind jij?” en de initiatiefnemer moet alles checken, verbaal of nonverbaal, bij de kat-uit-de-boom-kijkers. Te allen tijde moet alles wat het team doet of wat leden van het team doen, door het team als geheel worden gedragen, niet omdat ze overal in detail bij betrokken zijn, maar omdat ze weten dat degene die een bepaald besluit heeft genomen binnen het team degene is die van dat onderwerp het meest verstand heeft.

Met een Project Startup Hackathon heb je binnen een dag je team effectief en enthousiast aan de slag.