Author:
Leon Merkx is technisch manager voor mechatronica en technische software bij Alten.
Reading time: 4 minutes
Agile voor hardware staat nog in de kinderschoenen. De redenen om de werkwijze toe te passen in software gaan echter net zo hard op voor hardwareontwikkeling en de eerste pilots zijn succesverhalen. Leon Merkx van Alten ziet geen belemmeringen om hardwareprojecten agile aan te pakken.
In de softwareontwikkeling is agile werken het afgelopen decennium de standaard geworden. Hoewel er nog genoeg te winnen valt in de effectieve toepassing, is het gedachtegoed niet meer weg te denken en gaan softwarebedrijven ook niet meer terug naar een meer traditionele, planmatige aanpak. Want in Agile-projecten zijn ze flexibeler voor veranderende klanteisen, kunnen ze hogere kwaliteit leveren in kortere tijd en is de teammoraal hoger.
Het succes in de softwarewereld blijft niet onopgemerkt in meer hardwaregeoriënteerde omgevingen, een domein waar nu planmatig werken volgens het V-model de standaard is. Dit V-model komt ook uit de software-engineering en is daar ontstaan vanuit de noodzaak om de groeiende complexiteit in de hand te houden. Het hardwaredomein heeft het pas veel later geadopteerd. Agile is voortgekomen uit een reactie om de starheid van planmatig werken te doorbreken in een wereld vol onzekerheid.
Typische nadelen van een V-model voor softwareontwikkeling zijn onrealistische planningen door continu veranderende klantwensen, een focus op engineering in plaats van op die wensen, slecht inzicht in de projectstatus en integratieproblematiek. De vraag is of deze nadelen niet net zo hard gelden voor de hardwarewereld. Moet Agile dan niet ook daar de standaard worden?
Er zijn al enige successen geboekt met de toepassing van Agile binnen een hardwareomgeving. Buiten deze successen heeft het hardwaredomein hier en daar wel enkele elementen uit het gedachtegoed overgenomen óf de deliverables simpelweg afgestemd op het ritme van het Agile-softwareproces.
Minder flexibel
De keuze voor een planmatige of een Agile-werkwijze moeten we maken op basis van onzekerheid in effort en scope. Als een project voorspelbaar is en alle details zijn bekend, dan zal een planmatige aanpak het beste passen. We kunnen op efficiëntie sturen, omdat we vrij goed weten wat de klant wil en de werkzaamheden goed in te schatten zijn. Met toenemende onzekerheid zal Agile beter werken, omdat deze aanpak gericht is op flexibiliteit. De klant weet niet precies wat hij wil en de technische uitdagingen zijn (deels) onbekend. Dit laatste is typerend voor productontwikkeling, zowel voor software als voor hardware.
Hardwareontwikkeling is van nature wel minder flexibel dan softwareontwikkeling en de kosten van wijzigingen nemen over tijd toe. Wanneer specifieke functionaliteit niet past binnen de huidige architectuur, volgt er in software een ‘eenvoudige’ refactoringslag van de code. In hardware kan zelfs de kleinste late wijziging een enorme weerslag hebben. Een vervanging van een onschuldige elektronicacomponent kan zomaar meer vermogen en meer koeling vragen, met alle gevolgen van dien voor het héle product. Hierdoor zal er in het begin van een hardwareproject meer focus zijn op de architectuur dan bij een softwareproject.
Softwarebedrijven kiezen vaak voor Scrum als Agile-methodiek. Voor hardware lijkt dat ook de beste optie. Zodra de onzekerheid té groot wordt, bijvoorbeeld in meer issuegedreven omgevingen, zal Scrum echter minder goed werken. Regelmatig word ik geconfronteerd met bedrijven die Scrum toepassen, terwijl er dagelijks prioriteitsverstoringen zijn. Kanban is dan een beter alternatief, omdat die Agile-methodiek gericht is op continu plannen en prioriteren.
Voor het welslagen van een Scrum-aanpak moet het werk in elk geval op te splitsen zijn in kleine deliverables verdeeld over korte iteraties, uitgevoerd door een zelfsturend, lerend team. Dit is ook mogelijk binnen een hardwareomgeving. Volgens de Agile-filosofie levert elke iteratie bovendien een werkende deliverable op én neemt de klantwaarde gaandeweg toe. Dat lijkt lastiger bij hardware, omdat we daar de werkelijke klantwaarde pas realiseren als we (vrijwel) alle ontwerpelementen hebben opgeleverd en geïntegreerd tot het eindproduct. De klant kan echter in een vroeg stadium feedback geven op de opgeleverde deliverables en zijn wensen aanpassen. Zo kunnen we de klantwaarde alsnog optimaliseren en de verspilling beperken, zowel voor de planning als voor de ontwikkeling.
Meer specialisaties
Hoewel we nog maar aan het begin staan van de Agile-adoptie in de hardwarewereld, kunnen we al wel een paar lessen trekken uit pilotprojecten met Scrum. Ten eerste wordt de opsplitsing in kleine brokjes als lastiger ervaren in hardware. Bij software delen we de functionaliteit op en werken we die verder uit in user-story’s, waarvan de klantwaarde relatief makkelijk aan te tonen is binnen een iteratie. Bij hardware splitsen we het werk op op basis van componenten. Gevolg is dat we een beperkt aantal story’s voor de eindgebruiker schrijven en vooral veel technical story’s, waarvan de klantwaarde minder duidelijk is voor de traditionele productowner. Die zal daardoor moeite hebben met de prioritering.
In een hardwareomgeving moeten we de rol van productowner daarom toebedelen aan iemand met technische inhoud. Ook moeten we meer creativiteit aan de dag leggen om aan het einde van elke iteratie de voortgang te tonen aan de klant. Het is namelijk niet altijd mogelijk een werkend product op te leveren, maar we kunnen wél iets opleveren waarop de klant feedback kan geven en waarvan die vertrouwen krijgt, bijvoorbeeld een simulatie, mockup of blauwdruk.
Ten tweede kent een hardwareproject een grotere verscheidenheid aan specialisaties. Hierdoor kunnen teamleden minder makkelijk taken overnemen van elkaar. Dit maakt dat we het werk minder makkelijk kunnen verdelen en dat we werkzaamheden lastiger kunnen schatten en plannen.
Tijdens een planningsessie van een multidisciplinair team moeten we daarom de balans vinden tussen gezamenlijke betrokkenheid en benutting van individuele competenties. Het heeft weinig zin om een mechanicus een pcb-design te laten schatten, maar op de juiste momenten willen we wel competentie-overstijgende discussies kunnen voeren. Bij de werkinplanning moeten we vervolgens de capaciteit van de expertises meenemen, waardoor metrics als velocity iets genuanceerder worden. Bovendien moeten we rekening houden met de aard van de werkzaamheden bij hardwareontwikkeling: in het begin zal de focus meer liggen op architectuur, op het eind meer op integratie. Dit hoeft geen probleem te zijn, zolang de deliverables gericht zijn op klantfeedback, snelle integratie en testbaarheid.
