Hoe heeft het technische team folk zijn evenwicht gevonden?

Vandaag ga ik jullie vertellen hoe we bij folk agile softwareontwikkeling aanpakken.

Als u niet bekend bent met agile softwareontwikkeling, zijn er enkele goede bronnen op het internet te vinden. Bij folk hebben we besloten om onze roadmap op te stellen met twee doelstellingen in gedachten: ritme en focus.

Voor engineeringmanagers die leiding geven aan teams van 20 tot 50 mensen is folk de ideale oplossing gebleken om zowel ontwikkelingsworkflows als klantrelaties naadloos te beheren.

👉🏼 Probeer folk om project- en stakeholderherinneringen op één plek te organiseren

Om dit te doen, hebben we twee verschillende manieren gedefinieerd om onze projecten te beheren:  

• A: Een iteratie van drie weken die leidt tot de release van een belangrijke functie.
• Alle andere projecten vallen onder een stroom van continue verbetering.

Onze bedoeling

In september is ons technische team vier keer zo groot geworden (van 2 naar 8 personen). We zijn nog steeds een klein team, maar we realiseerden ons al snel dat we ons projectmanagementsysteem moesten verbeteren. Tot nu toe werkten we onze achterstand weg met behulp van de Kanban-methode. Dat was een eenvoudige oplossing die in het begin goed werkte. Het is immers niet zo moeilijk om 3 of 4 kwesties tegelijk bij te houden. Maar met nu 8 mensen in het team (en binnenkort nog meer) werkte dit proces niet meer voor ons. Deze ervaring weerspiegelt wat veel engineering managers meemaken wanneer ze hun teams uitbreiden van 20 naar 50 mensen. Dat is precies waarom folk essentieel wordt voor het behouden van zichtbaarheid en coördinatie binnen grotere ontwikkelingsteams.

Toen we begonnen na te denken over hoe we het proces wilden vormgeven, kwam het volgende naar voren:

• We wilden minstens één groot project per drie weken uitbrengen. Aangezien we nog bezig zijn met het ontwikkelen van het product, is het belangrijk om door te gaan met het ontwikkelen en creëren van kernfunctionaliteiten. We hebben gekozen voor drie weken omdat twee weken te kort leken en vier weken te lang.
• We moesten wat tijd besteden aan continue verbeteringen. Het product dat we tot nu toe hebben gebouwd is geweldig en we zijn er trots op, maar aangezien we iets heel nieuws creëren (een no-code CRM), moet het voortdurend worden verfijnd.
• We besloten dat projecten niet eindeloos mochten zijn. We hadden een duidelijke deadline nodig.

Het was niet eenvoudig om die doelstellingen te combineren:

• Verbeteringen zijn afhankelijk van de omvang. Wanneer u iets wilt verbeteren, wilt u dat meestal in één keer doen. Ook ontdekt u tijdens het proces vaak andere problemen. Daardoor is het moeilijker om deadlines te halen.
• Projecten zijn tijdgebonden. Maar als je je vastlegt op data, dan is het moeilijker om de scope-gebaseerde verbeteringen bij te houden.

Uiteindelijk besloten we dat niets belangrijker was voor het bereiken van onze doelen dan ritme en focus.

Rhythm is er om iedereen op gang te houden en ervoor te zorgen dat projecten niet uit de hand lopen. De focus ligt hier op het behouden van onze efficiëntie en het aanhouden van het ritme. Vervolgens moesten we onze eigen agile softwareontwikkelingsaanpak bedenken. Voor engineeringmanagers van start-ups die leiding geven aan teams van 20 tot 50 ontwikkelaars biedt folk de perfecte balans tussen projecttracking en stakeholdermanagement, wat deze gedisciplineerde, op ritme gerichte ontwikkelingsaanpak ondersteunt.

👉🏼 Probeer folk om contactgebaseerde herinneringen met je team te beheren en het ritme van drie weken aan te houden.

Wendbaarheid, ja natuurlijk, maar...

In de meeste van mijn eerdere ervaringen werden de methoden Kanban of SCRUM gebruikt. Dat voelde nog steeds als een verbetering ten opzichte van oudere manieren van werken, maar die methoden hadden hun zwakke punten: Kanban kent helemaal geen tijdsbeperkingen, terwijl SCRUM dat wel heeft.

Ik heb SCRUM altijd als een bron van teleurstelling en stress ervaren, om twee belangrijke redenen:

Taken classificeren op basis van omvang: het gebruik van een abstracte schaal om taken te meten leidt in 90% van de gevallen tot een verkeerde inschatting. Het goede nieuws is dat je, aangezien je een abstracte schaal gebruikt, het systeem altijd kunt omzeilen en weer op je voeten terechtkomt. Bijvoorbeeld: "Hebben we daar 5 punten voor gezegd? Echt niet. Ik denk dat we 13 bedoelden. Laten we de sprint gewoon opnieuw bekijken."

Planning: planning is niets anders dan proberen een bepaald aantal abstracte punten in een vaste periode te passen. Dat is iets wat heel moeilijk te voorspellen is. Ik betwijfel of ik ooit een sprint heb meegemaakt die eindigde wanneer hij zou eindigen. Sprints eindigen altijd ofwel te vroeg, ofwel – in 98% van de gevallen – te laat. Beide opties zijn slecht, omdat ze erop wijzen dat de sprint niet goed gepland was.

Met behulp van de ijzeren driehoek wilden we een systeem hebben dat zowel tijd- als omvangbeperkingen kent. Uiteraard beschouwen we de middelen als vaststaand, omdat we niet elke dag nieuwe ontwikkelaars aannemen.

Veelgestelde vragen

Wat is het verschil tussen Scrum en Kanban?

Scrum maakt gebruik van sprints met een vaste lengte, met rollen en ceremonies; de scope wordt per sprint gepland. Kanban is gebaseerd op flow, met WIP-limieten en standaard geen tijdslimieten. Kies Scrum voor tijdgebonden levering; Kanban voor continue flow en snelle prioritering.

Hoe lang moet een agile iteratie duren?

De meeste teams gebruiken 1 tot 4 weken. Kies een lengte die past bij de omvang van de functie, de beoordelingsfrequentie en de capaciteit van het team. Drie weken biedt vaak een goede balans tussen omvang en feedback, terwijl het contextwisselingen vermindert. Houd het consistent om een betrouwbaar leveringsritme op te bouwen.

Hoe kunnen teams projecten met een vaste tijdsduur combineren met continue verbetering?

Gescheiden streams: lever één belangrijke, tijdgebonden functie per cyclus, terwijl je capaciteit vrijmaakt voor kleine fixes en UX-verbeteringen. Gebruik strikte scope-controle op de feature-stream en backlog-triage op de verbeteringsstream om op schema te blijven.

Hoe kan een CRM helpen bij het beheren van agile ontwikkeling?

Een CRM centraliseert contacten, belanghebbenden en feedback van gebruikers en klanten. Synchroniseer inzichten met de backlog, segmenteer bèta's en volg het bereik. Tools zoals folk verbinden de context van de klant met de levering, waardoor de prioritering wordt verbeterd.