De mensen die vol vertrouwen antwoordden op bovenstaande vraag beginnen vaak met het opsommen van alle Agile Practices die ze toepassen, of het nu Scrum, Kanban, retrospectives, stand-ups, demo's of Test Driven Development is. De aarzeling van de anderen komt meestal voort uit de onzekerheid over wat Agile nu eigenlijk is. Wanneer doe je aan Agile? Wat is genoeg?

Wat is precies Agile werken?

In plaats van Agility te zien als een rigide ding, helpt het om het te zien als een volwassenheidsschaal.Iedereen en elk team werkt op een Agile manier, maar niet elk team heeft hetzelfde niveau van volwassenheid bereikt. Hoewel de verschillen tussen teams of zelfs individuen groot kunnen zijn, net als bijKaizen ( Continu Verbeteren) of Karate Belts, zal niemand ooit het maximum bereiken. Er is altijd ruimte voor verdere verbetering.

Over verbetering in Agile werken gesproken: het toepassen van Agile Praktijken zal over het algemeen je Agility verbeteren. Maar om dat niveau van Agility niet te laten stagneren en echt te laten groeien, heb je meer nodig dan het kopiëren en toepassen van Agile Practices. De sleutel is om de mindset van Continue Verbetering in te bouwen door je manier van werken consequent te valideren aan de hand van de 12 Agile Principes.

Agile werken betekent dat je je manier van werken voortdurend vormgeeft en verbetert door deze te toetsen aan de Agile Principes. Herzie je proces regelmatig, met de Agile Principes als richtlijnen en de Agile Practices als inspiratie!

Agile werken betekent dat je je manier van werken voortdurend vormgeeft en verbetert door deze te toetsen aan de Agile Principes. Herzie je proces regelmatig, met de Agile Principes als richtlijnen en de Agile Practices als inspiratie!

Hetzelfde geldt voor Lean werken. Het betekent dat je je werk voortdurend evalueert aan de hand van de7 principes van Lean Software Development.

Deze 19 principes kunnen een beetje overweldigend zijn, dus geïnspireerd door deze principes heb ik 7 stappen gecreëerd om de Agility van je IT-teams te vergroten.

7 stappen om de wendbaarheid van nieuwe of bestaande teams te vergroten

Denk aan de hele levenscyclus van productontwikkeling voor het product waar je momenteel aan werkt. Het begint bij de waarde die je wilt creëren voor de klant of de aanname die je wilt verifiëren. Het eindigt bij de levering van de kleinste oplossing voor dat resultaat aan de eindklant. Laten we met dat proces in gedachten 7 stappen doorlopen die je zullen helpen om de wendbaarheid van je IT-teams te vergroten.

1. Visualiseer, visualiseer, visualiseer

Maak fysiek zichtbaar waar je teams aan werken.Visualiseren zorgt voor meer transparantie en verlaagt de drempel voor anderen om deel te nemen aan discussies. Een zichtbare workflow biedt een structuur voor je samenwerking en maakt diepgaandere discussies mogelijk. Hier is een kleine subset van manieren om te visualiseren waar je team aan werkt:

• visualiseer de werkstroom via een fysiek Kanban-bord, waarbij je sticky notes gebruikt om de waarde die je probeert te creëren weer te geven en lanes die de verschillende stappen die nodig zijn weergeven. Annoteer de sticky notes om belemmeringen zichtbaar te maken. Voeg avatars toe om te laten zien waar iedereen in het team aan werkt.
• Visualiseer de customer journey, product scope en releases door de User Story Map zichtbaar te hebben in de teamkamer. Je kunt ook de schermmock-ups of productscreenshots aan de muur hangen. Stel de persona's op en maak een lijst van de informatie die je hebt over de eindgebruikers.
• Breng discussies op gang over het ontwerp van je software door afdrukken van de architectuurdiagrammen in de teamruimte te hangen. Visualiseer ook je domeinmodel om ervoor te zorgen dat iedereen dezelfde taal spreekt in deze discussies.
• Begrijp de gebruikers door inzichten over uw product te visualiseren. Welke functies worden gebruikt en welke niet? Hoeveel gebruikers hebben te maken met fouten?
• deel een gemeenschappelijk doel door de voortgang naar de volgende mijlpaal of MVP te visualiseren. Eventuele blokkades in je voortgang, bijvoorbeeld een storing in je bouwpijplijn, moeten zichtbaar zijn op een tv-scherm zodat iedereen in het team er meteen van op de hoogte is.

TIP: Als je de volgende keer bezoek krijgt, vooral van zakelijke belanghebbenden of sponsors, loop dan met ze door de visualisaties in je teamkamer. Zo krijgen ze 'Boots on the Ground' en waardevolle inzichten over het project. Het zal het vertrouwen een boost geven.

2. Samenwerking > documentatie

Voor het bouwen van complexe producten zijn meerdere vaardigheden en meerdere mensen nodig.In plaats van een document op te stellen en het aan de volgende persoon te geven, kun je je beter persoonlijk richten op samenwerking en kennisoverdracht. Een document kan snel verouderd zijn en veel tijd kosten om up-to-date te blijven, terwijl je liever middelen besteedt aan het echte werk.

Door informatie face-to-face te delen of deel te nemen aan de brainstorm, krijgt iedereen die betrokken is bij het ontwikkelingsproces veel meer inzicht en zal het werk beter en kwalitatiever kunnen worden gedaan. Hier zijn enkele ideeën:

• Loop regelmatig met het hele team door het softwareontwerp, de architectuur, de customer journey en het domeinmodel.
• Begin de ontwikkeling van een verhaal met een kick-off waarin de analist het verhaal en de beweegredenen ervan face-to-face uitlegt. Vergeet niet om je toegewijde tester erbij te betrekken als je die hebt!
• Pair programming is een van de beste manieren om van elkaar te leren en een team te krijgen dat volledig op één lijn zit.

3. Snelle feedback

Het bouwen van een product is een teamprestatie en vereist veel werk. We willen er zeker van zijn dat we altijd het juiste doen met de juiste kwaliteit.De enige manier om te weten of je waardevol werk aflevert, is door snelle feedback te geven - en te krijgen - van de gebruikers op de functies die je hebt gebouwd, maar ook van de volgende persoon in je workflow. Hoe sneller de feedback, hoe kleiner de kans dat de volgende persoon in de rij ontevreden zal zijn over de kwaliteit van het werk dat je hebt afgeleverd voordat je verbeteringen aanbrengt. Hier zijn een paar manieren waarop je snelle feedbacklussen kunt bouwen:

• valideer vroege mockups of rapid prototypes van de oplossing met de eindgebruikers voordat je begint met de daadwerkelijke ontwikkeling. Maak er een gewoonte van in het team dat iedereen de tijd neemt om het product dat ze hebben gebouwd te spelen en te testen om het inlevingsvermogen van de gebruikers te vergroten.
• breng snel en vaak uit. Als je maar één keer per jaar iets uitbrengt, weet je pas na een jaar of het de investering waard was.
• Doe een technische review van elk verhaal aan het einde van de analyse om de kwaliteit van de analyse te verbeteren en belemmeringen tijdens de ontwikkeling te voorkomen. Doe ook een technische review van elke story die is uitgewerkt om de kwaliteit van de uitwerking te verbeteren.
• Valideer de voorgestelde architectuur en de daaruit voortvloeiende wijzigingen met het team om in een vroeg stadium feedback te krijgen over de haalbaarheid. Organiseer daarnaast regelmatig team retrospectives en retrospectives met de externe stakeholders of medewerkers om ieders feedback op regelmatige basis vast te leggen. Gebruik deze feedback om je product of processen te verbeteren!
• Maak nieuwe functies zo snel mogelijk beschikbaar voor testgebruikers, belanghebbenden en de echte eindgebruikers. Vergeet ook niet om inzichten te verzamelen over hoe je gebruikers de functies gebruiken die je eerder hebt gebouwd.

4. Creëer een soepele workflow

Om je team als een geoliede machine te laten werken, moet je zorgen voor een soepele workflow. Een goede doorstroming betekent dat gepland werk in korte tijd wordt afgeleverd. De investering van de organisatie zal een stuk lager zijn voordat ze de resulterende inkomsten zien.

Om dat punt te bereiken,begin je met het expliciet en zichtbaar maken van je epic en story workflow met een Kanban-bord. Verbeter het vervolgens verder. Hier zijn enkele tips:

• definieer WIP-limieten (Work In Progress) voor de verschillende stappen in je proces.
• verminder de hoeveelheid 'stationair' werk door wachtrijen als 'klaar voor ontwikkeling', 'te testen' en vooral 'wachtend op implementatie' kleiner te maken. Trap niet in de Scrum-val dat je werk klaar is als je het verhaal hebt geïmplementeerd. De waarde wordt pas geleverd als de functionaliteit beschikbaar is in productie.
• Meet het totale aantal post-its dat doorloopt in je flow, of het nu gaat om een story in analyse, review, ontwikkeling of uitrol. Neemt het toe in de tijd?
• pas de mantra toe: "Stop met beginnen. Begin met afmaken!" Pak niet zomaar een nieuw verhaal op voor analyse of ontwikkeling als je een collega kunt helpen om een verhaal af te maken dat al bezig is.
• Zwerm impediments, moeilijke stories of de initiële projectopzet uit met het hele team. Dit zal de doorlooptijd en de rimpeleffecten die het zou hebben drastisch verminderen.

5. Splits werk op in kleine delen

Door werk op te splitsen in kleine delen kan je team zo min mogelijk werk verrichten voordat het daadwerkelijk begint met het opleveren van functionaliteit. Dit zorgt niet alleen voor een snellere feedbackloop, maar geeft je team ook een gevoel van voldoening telkens als ze een stuk werk af hebben.

Het opdelen van werk in kleine delen kan in het begin een ontmoedigende taak lijken. Hier lees je hoe je je werk kunt opdelen:

• Splits een groot stappenplan of product op in kleine releases of Minimal Viable Product (MVP) incrementen op basis van de waarde die het levert, terwijl je rekening houdt met het klanttraject. Richt je op het live brengen van de eerste release voordat je aan de volgende release begint.
• Splits releases of MVP's op in Epics of features die je moet opleveren. Focus op het afronden van de belangrijkste Epics voordat je aan de volgende Epic begint.
• splits Epics / functionaliteiten op in Stories die in 2 of maximaal 3 dagen kunnen worden geïmplementeerd. Focus op het afmaken van lopende stories voordat u aan nieuwe stories begint.

Stel na het opsplitsen van het werk in Epics en Stories prioriteiten voor de belangrijkste stukken voor een MVP. Op deze manier doe je altijd het minste werk om daadwerkelijk te beginnen met opleveren zonder het grotere geheel te missen.

6. Resultaat > output

Het voortdurend afstemmen van je manier van werken zorgt voor een soepele workflow en een hoge output.Het is echterbelangrijker om het juiste resultaat te leveren dan een hoge output. Anders geef je alleen maar geld uit dat de organisatie ook anders had kunnen besteden. Dus:

• evalueer waar je aan werkt. Wat is de waarde die je project zal opleveren?
• Richt je op het afmaken van werk in uitvoering in plaats van op het starten van nieuw werk.
• Zorg ervoor dat je team zijn werk afmaakt tot het punt waarop het live naar de klant wordt gebracht. Al het analysewerk dat nog niet ontwikkeld is, alle code die geschreven is en nog niet in productie is, is nog steeds 'afval', omdat het geen waarde oplevert voor de eindgebruikers.

7. Kwaliteit & eenvoud

Het leveren van kwaliteit moet ieders focus zijn binnen het ontwikkelproces. Zonder die focus ben je er zeker van dat je suboptimale resultaten levert aan de volgende (of laatste) stap in het proces. Denk aan bugs, belemmeringen en verwarring die uiteindelijk meer tijd en middelen kosten. Om je focus optimaal te houden en ongelukken te voorkomen, werk je altijd aan de eenvoudigste oplossing die aan de doelen voldoet. Een eenvoudigere oplossing is gemakkelijker te begrijpen, te implementeren, uit te leggen en te ondersteunen.

• Implementeer alleen wat je nu nodig hebt en wat binnen het bereik van het huidige verhaal, de piek of het epic valt. Elke extra scope kan resulteren in werk dat niet wordt gebruikt.
• Elke vorm van inefficiëntie in code of de manier van werken is een technische schuld waar je organisatie uiteindelijk voor zal betalen. Verwijder consequent kleine delen van deze technische schuld. Door kleine delen te verwijderen, is er op korte termijn geen negatieve impact op de prestaties van het team en profiteer je toch van de positieve resultaten op middellange en lange termijn.
• Gebruik tools zoals Sonar om de kwaliteit van code te beoordelen. Maak er een gewoonte van om bij het implementeren van nieuwe functies de technische schuld in de code die je aanpast te verminderen. Continue, kleine refactorings belemmeren de levering van waarde niet, maar een grote herschrijving, wanneer de technische schuld te hoog is, zal een enorme impact hebben.

Takeaway

Het continu verbeteren van de manier van werken, met de Agile en Lean principes als leidraad, is nog steeds niet gemeengoed in elke (IT) organisatie. Deze blogpost geeft een aantal uitvoerbare stappen die je kunt nemen om de Agility van je IT-teams te vergroten. Je hoeft echter niet meteen te beginnen met het implementeren van al deze stappen. Begin met een paar stappen die haalbaar zijn voor jou en je team, evalueer, verbeter en herhaal. Zo vergroot je de Agility van je IT-teams op een Agile manier!

Als je meer informatie, tips, richtlijnen of meer wilt, neem dan contact op met onze Agile coaches en zij helpen je verder!