Reach Digital splitst in twee Agile Teams

Afgelopen zomer hebben we het als één team georganiseerde development team van e-commerce specialist Reach Digital opgesplitst in twee autonome, agile teams. Het doel: een schaalbare organisatiestructuur introduceren, zodat we op een goed georganiseerde manier kunnen blijven groeien.

Het opsplitsen in autonome teams zorgt voor meer zelfstandigheid en vrijheid bij developers, doordat taakverdeling, communicatie met klanten en inhoudelijke beslissingen volledig binnen het team gebeuren. Het heeft daarnaast als resultaat dat er tijd vrijkomt bij de customer success managers, zodat zij zich meer kunnen concentreren op het faciliteren van het scrum proces en samen met de klant naar de lange termijn kunnen kijken.

Teams

De teams zijn samengesteld op basis van kennisprofiel (ervaring en skillset) en interesse van onze developers. Bij de samenstelling is ook rekening gehouden met de bestaande developer pairs en de projectspecifieke kennis die bij de developers aanwezig is. Elk team is gekoppeld aan verschillende projecten van het e-commerce portfolio en een toegewijde customer succes manager. Doordat kennis en skills gebalanceerd zijn hebben beide teams de vaardigheden in huis om voor elk type klant aan de slag te kunnen gaan.

Planning

In de vorige situatie was de customer success manager volledig verantwoordelijk voor de planning. In de nieuwe situatie verschuift de verantwoordelijkheid, van het op de man plannen van issues, naar het plannen op teamniveau. Hierdoor kan het team zelf rekening houden met individuele expertise en beschikbaarheid van developers binnen het team. Voor onze klanten belangrijk, want zodoende is er altijd kennis van een specifiek project. De customer success manager zal nog wel verantwoordelijk blijven voor het vullen en bespreken van de backlog, faciliteren en begeleiden van de sprint.

Vragen van klanten (via Jira, Slack, telefoon, of e-mail) werden door de customer success manager beoordeeld als front- en/of back-end development, op complexiteit geschat en gekoppeld aan een programmeur. In de nieuwe situatie kijkt de customer success manager mee om te beoordelen of klantvragen binnen gealloceerde tijd van klanten past, om op basis hiervan de planning op lange termijn af te stemmen.

Scrum proces

Aan het huidige scrum proces is weinig veranderd. Dagelijks worden binnen een agile team standups gehouden zodat ieder teamlid op de hoogte is van de lopende projecten en opgepakte issues. Door iedereen binnen het team dagelijks de kans te geven te spreken over waar hij/zij mee bezig is kan er nog sneller richting een oplossing worden gewerkt. Hiermee behalen we een mooie efficiëntieslag. Een team zal daarnaast zelf regelmatig projectspecifieke én niet-projectspecifieke retrospectives houden. Zo kan worden geëvalueerd hoe sprints verliepen en hoe de samenwerking tussen teamleden verbeterd kan worden.

De customer success managers zullen de contactmomenten met de klant (sprint planning, sprint review en retrospective) blijven faciliteren en blijven dus het vaste aanspreekpunt voor de klant (ook als het niet gerelateerd is aan ontwikkeling).

Roadmaps

Net als in de oude situatie zullen opdrachtgevers direct contact blijven hebben met developers gedurende projecten en in de scrum meetings. Op deze manier kunnen we samen tot de beste oplossing voor een vraagstuk blijven komen, kunnen we goed de prioriteit inschatten van de ideeën die klanten bij ons neerleggen en kunnen we onze eigen input op het project blijven geven. Door de zelfstandigheid van de teams kan er, vanuit de customer success manager en lead architect, nog meer aandacht naar de visie van de klant op lange termijn. Bovendien kan er ook nog meer aandacht naar de roadmap, welke we samen met klanten op basis van de visie opstellen. Vaak wordt hierbij 1 à 2 jaar vooruit gekeken.

Kennis delen

Het splitsen in twee autonome teams zorgt voor meer zelfstandigheid en vrijheid voor de developers. Een team kan nu namelijk zelf de balans tussen productie en vergaring van kennis bepalen, natuurlijk met inachtneming van de planning.

Ook horizontaal (tussen bijvoorbeeld frontend developers van verschillende teams) blijven we kennis delen. Dit zal gebeuren tijdens de chapter meetings, welke begeleid worden door de lead developers.

Het belangrijkste voordeel van het onderling blijven delen van kennis is dat in elk team meerdere developers zitten met kennis over een bepaald onderwerp. Zo kan er te allen tijde aan een project worden gewerkt en zijn projecten niet meer afhankelijk van specifieke developers.

Op kantoor en remote

Ondanks dat we net zijn verhuisd naar het nieuwe kantoor, en het prettig werkt als we fysiek bij elkaar in de buurt zijn, hebben we de afgelopen maanden meer dan normaal op afstand gewerkt. Doordat onder andere de standups, sprint reviews en het contact met klanten prima remote kan, blijven de developers elke dag met elkaar communiceren over de status van projecten en werkzaamheden.

Wanneer de aanwezigheid op kantoor weer kan worden opgeschaald, zullen we de teams verdelen over de twee verdiepingen. Door teams dicht bij elkaar te zetten, houden we onderlinge communicatie efficiënt en persoonlijk.

Schaalbaar

Nieuwe developers zullen worden opgeleid binnen het team. Door te werken in teams kunnen ze gecontroleerd meedraaien binnen projecten en hebben ze zowel backend als frontend kennis tot hun beschikking. Wanneer de teams significant groeien, is het, dankzij de schaalbaarheid van deze werkwijze, mogelijk om uit te breiden naar drie teams (of meer). Wat de ideale teamgrootte is, zullen we in de toekomst gaan ontdekken.