In eenvoud

Simplicity… Hou het simpel, eenvoudig oftewel gebruik je gezond verstand. Dat zijn maar enkele zaken die je zult horen vallen wanneer je in één van onze teams actief bent. Wij vinden het belangrijk dat we niet in de val lopen het onszelf te moeilijk maken. Gaan we daardoor een uitdaging uit de weg? Helemaal niet! Wij houden van een uitdaging maar gaan wel stap per stap bekijken hoe we die uitdaging op een zo eenvoudige manier kunnen tackelen.

Voor The Beehive zien we drie maal het belang van in eenvoud te werken. De eerste is in ons eigen team waarbij we vooral oog hebben voor onze interne communicatie. De tweede pijler is de link met de klant waarbij we de focus leggen op transparantie en de derde poot is onze technische poot. Eenvoudige software om zo het meeste waarde o te brengen.

De eenvoud in ons eigen team

De dag is gekomen. We mogen met The Beehive een team opstarten bij een nieuwe klant. Enkele teamleden kennen elkaar en hebben zelfs al samen op een project gewerkt. Sommigen hebben dit nog niet meegemaakt en maken dus een soort van aanpassingsperiode door. Dat vraagt om de nodige afspraken in de manier van werken met elkaar. Noem het gerust een playbook. Dat playbook moeten we neerschrijven zodat we erop kunnen terugvallen wanneer sommige afspraken irrelevant worden, aangepast moeten worden of wanneer er iemand nieuw in het team komt.

In dat playbook staan volgende zaken opgelijst:

• De manier van communiceren in ons team, wat steeds op een open en veilige manier gebeurt.
• Communicatie met de klant
• Communicatie met de teams van de klant.
• Hoedanigheid (teamlead, developer, architect,...) waarin iedereen met de klant praat, om zo duidelijke rollen op te nemen in het team en verantwoordelijkheden over een specifiek aspect van het project te verdelen.

In dat playbook gaan we het onder meer hebben over de manier van communiceren onderling, dat moet steeds op een open en veilige manier. Hoe we die veilige omgeving creëren komt aan bod in een volgend artikel. Communicatie met de klant komt aan bod, ook andere teams bij de klant waar we misschien en wellicht afhankelijkheden hebben in ons dagelijks werk. We spreken af wie in welke hoedanigheid (teamlead, developer, architect, …) met de klant praat zodat het voor iedereen duidelijk is wie welke rol opneemt binnenin het team en wie de verantwoordelijkheid over een specifiek aspect van het project opneemt.

Als team willen we de communicatielijnen zo kort mogelijk houden. Dat doen we door enkele vaste momenten in een sprint in te plannen. Dagelijks zien we elkaar op een afgesproken uur waarbij onze vooruitgang enblokkerende factoren bespreken, of gewoon advies vragen bij een bepaald onderwerp. In de sprintplanning houden we overzicht op het werk en toetsen we af of we met de juiste prioriteiten bezig zijn. Uiteraard leer je hierdoor ook wat je aankan als team binnenin de afgesproken periode van de sprint. Als laatste is het belangrijk om regelmatig ‘de temperatuur in het team te meten’. Dit doen we door retrospectieven in te plannen na elke sprint. We houden dit eenvoudig maar aangenaam en veilig waardoor het geen sleur wordt, wat wel een veelvoorkomend struikelblok is in veel teams. ‘Inspect and adapt’ als basis agile principes om te groeien en toch eenvoudig te houden.

Je leest dit nu misschien en denkt bij jezelf, “ik lees hier niets wereldschokkends…” en daar heb je volledig gelijk in! Dit is niet moeilijk, je moet gewoon stilstaan bij de samenstelling van je team en wat je als team nodig hebt om zo optimaal mogelijk aan de slag te kunnen. Eenvoud en simplicity staan gelijk aan afspraken maken en communiceren met elkaar. Doe dit NIET en je wordt vroeg of laat stuurloos als team. Dus maak afspraken, schrijf ze op en hou je eraan. Dit is niet moeilijk maar het is gemakkelijker om het niet te doen of een hele complexe structuur uit te werken en laat dat nu net iets zijn waar veel teams zich aan laten vangen.

“Het project moet ook vanuit de business noden gestuurd worden”

Eenvoud in onze relatie en samenwerking met de klant

Eén van de grote uitdagingen is dat ICT onvoldoende weet wat de klant wil en dat de klant niet weet wat ICT kan en tegen welke tijd en kost. Daarom is het belangrijk dat we allen dezelfde taal spreken zodat we elkaar verstaan. Maar hoe vertaal je dit nu concreet in een business project op een eenvoudige en laagdrempelige manier.

Eérst en vooral is het belangrijk dat iedereen van het team begrijpt wat het business doel is van het project en dit niet louter bekijkt met zijn eigen (technische) bril. Dit bekom je door het volledige team te betrekken vanaf het begin van het project, en dit van ontwikkelaars tot de eindgebruikers, tot de effectieve uitrol ervan en dit tijdens gezamenlijke momenten tijdens een project. De ideale kruisbestuiving kan spontaan tot stand komen door samen te gaan zitten.

Het project moet ook vanuit de business noden gestuurd worden. Daarom is het belangrijk dat we eerst bepalen wat het einddoel is en dat we dan bepalen hoe we er gaan komen. In Jip en Janneke taal gaan we die grote olifant gaan verdelen in kleinere beheersbare functionele doelstellingen die we volgens prioriteit gaan implementeren en uitrollen.

Ook is het belangrijk om vrij snel boven water te komen omdat het beschrijven van de noden één ding is, maar het valideren ervan pas goed kan gebeuren door het product te gaan gebruiken en dit zowel voor de functionele als niet functionele noden.

Open en transparante communicatie is ook “key” tussen de partij die een product bouwt en de klant. Tracht dus te vermijden dat de communicatie enkel gebeurd op basis van “green and red flags” rapporteren maar ook door de resultaten te tonen om de x weken. Ook is het belangrijk om de uitdagingen te kunnen benoemen en niet te denken van “oei als ik problemen ga melden gaat men denken dat we het project niet onder controle hebben”. Het tegendeel is waar! Hoe beter en sneller we een probleem kunnen duiden hoe beter we het project onder controle hebben. De kunst van het weten wat je niet weet is dus enorm belangrijk.

Eenvoud technisch

Ons doel blijft om value op te leveren voor u als klant, doormiddel van het bouwen van een software systeem dat voldoet aan de gegeven functionele, beveiliging en performantie noden terwijl deze zo overzichtelijk en onderhoudbaar blijft als mogelijk. Daartoe zijn onze technische doelstellingen eenvoud, modulariteit en kwaliteit.

Eenvoud

Door simpliciteit verlagen we zoveel mogelijk het aantal verschillende onderdelen in het systeem waardoor de verstaanbaarheid hoog blijft en het aantal delen dat kan falen verlaagd wordt wat een positieve impact heeft op de beschikbaarheid van het systeem. Daarnaast houden we de niet-essentiële complexiteit zo laag mogelijk zodat verdere uitbreidingen van het systeem snel en efficiënt kunnen gebeuren.

Modulariteit

Door modulariteit verhogen we de testbaarheid van het systeem en verlagen we de afhankelijkheid tussen verschillende delen van het systeem. Daarnaast laat dit ons toe om aanpassingen te doen in het systeem met minimale impact op de niet gerelateerde delen waardoor onverwacht gedrag vermeden word.

Kwaliteit

Kwaliteit betekent dat we de volgende 2 metrics zo laag mogelijk willen houden: Het percentage van aanpassingen dat tot falen leid in productie, en hoe snel het falen opgelost kan worden eens het gededecteerd is.

‍