Het bouwen van cyberfysieke producten, hardware, machines, modules en componenten met agile teams is een uitdaging en vereist vaak contextuele aanpassingen om effectief te zijn.
Tijdens het webinar over "Agile voor de ontwikkeling van fysieke producten" benadrukte Ali het belang van het organiseren van teams rondom het product. Om precies te zijn: rondom de architectuur van het product.
Ali, zou je dat iets verder kunnen toelichten?
Ik heb me altijd sterk ingezet voor het idee van stabiele teams, teams die zo georganiseerd zijn dat engineers veel langer dan de looptijd van een project kunnen blijven samenwerken. Het uit elkaar halen van teams is een pijnlijk neveneffect van wat we 'resource management' noemen. Resource management, gecombineerd met de voortdurende druk van urgentie, reduceert slimme en capabele engineers tot inwisselbare instrumenten om een klus te klaren. Hoewel dit niet goed is voor de engineers zelf, is de eeuwige zoektocht naar capaciteit absoluut niet bevorderlijk voor de projectontwikkeling. De vraag is dan ook: wat is het alternatief? Welnu, het alternatief is: stabiele teams.
Hoe "stabiele teams" er in 'jouw' situatie uitzien, hangt sterk af van de context. Jouw situatie vereist misschien duizenden engineers om een complex product te ontwikkelen, of je bevindt je wellicht in een situatie waarin je team uit slechts 10 experts bestaat die aan verschillende projecten werken. Zeer verschillende contexten met verschillende nuances.
Een nuance die algemeen toepasbaar is, is het idee om je teams te organiseren rond een duurzame technologische structuur: een productfamilie, een product of een module. Het bedrijf waar je werkt, bouwt en blijft bouwen aan die productfamilie, dat product of die module, en onderhoudt de bestaande systemen. Omdat dat een constante factor is in de levensduur van 'jouw' bedrijf, waarom zou je je teams daar dan niet omheen organiseren?
Hoe rijmt dit met de stelling "organiseer rondom waarde"? Het lijkt erop dat we bij complexe cyberfysische systemen niet alleen kunnen focussen op de uiteindelijke klantwaarde, en zelfs niet op de waarde die mogelijk voor een interne klant, zoals een ander team of een andere afdeling, kan worden gegenereerd. Agile Release Train (ART) . Moeten we ons meer richten op de taken die de afzonderlijke onderdelen van het systeem uitvoeren?
Een groot en complex systeem kan door duizenden mensen worden ontworpen, geïndustrialiseerd en geproduceerd. Iedereen die enigszins bekend is met Agile-frameworks weet dat Scrum dit beschrijft. het Scrum-team a is het meest effectief wanneer het 10 of minder mensen bevat. Schaalbaar Agile-raamwerk beschrijft de Agile Release Train Een virtuele organisatie functioneert het best met minder dan ongeveer 125 medewerkers. Maar wat als het er duizend zijn? Een systeem bestaat uit verschillende onderling verbonden onderdelen, die, afhankelijk van het systeem, afzonderlijk verkoopbaar zijn. Denk aan modules van een vliegtuig, auto-onderdelen of modules van een transportband. De onderdelen worden op voorraad gehouden en afzonderlijk verkocht, ook al weten we dat het product "het vliegtuig", "de auto" of "de transportband" is.
Ik heb gemerkt dat de term 'waarde' niet goed aanslaat bij engineers. Engineers werken aan een klein onderdeel van een grotere module of systeem waarover ze geen volledige controle hebben. Dus wat levert 'waarde' op? In plaats van in de val te lopen van te veel Agile-terminologie (iemand die ik bewonderde noemde het 'Agile-onzin'), geef ik er de voorkeur aan om te communiceren in een taal die engineers begrijpen: 'productfuncties' of 'productarchitectuur'. De architectuur van een product bestaat uit verschillende modules die bijdragen aan de functionaliteit van een systeem. Het is de functionaliteit die waarde creëert voor de klant. Idealiter organiseren we ons daarom rond de functies van het product. Dit voorkomt dat je kunt zeggen: "maar mijn component werkt wel...". Afhankelijk van de competenties binnen ons team, moet je mogelijk enigszins afwijken van een productfunctiegerichte aanpak.
Is dat niet in tegenspraak met ons algemene idee dat Agile Release Trains voornamelijk moeten bestaan uit teams die op dezelfde stream zijn afgestemd, en niet uit componentteams?
Ik heb gemerkt dat de concepten zoals beschreven door Skelton en Pais (boek: Team Topologies ) zijn geldig, maar hebben mogelijk een nieuwe invulling nodig onder ingenieurs. Het is dus geen tegenstrijdigheid, maar eerder een herpositionering. Gezien de situatie (en de producten die we ontwikkelen), hebben we een mix nodig van teams met één competentie en teams met meerdere competenties. Sommige teams richten zich op gemeenschappelijkheid en platformisering (bijvoorbeeld hergebruik van technologieën), terwijl andere zich richten op klantgerichte productfunctionaliteiten (bijvoorbeeld behuizing, verpakking, HMI, enz.).
Omdat er zoveel teams bij betrokken zijn, die allemaal aan complexe systemen werken, lijkt het gebruik van het dubbele V-model of het "W"-model passend. Kunt u ons iets meer vertellen over het "dubbele V"-model en de ideeën erachter?
Het Dual Vee-model ( van Forsberg en Mooz , 2006) voegt een dimensie toe aan een V-model. Hoewel een groot project bepaalde fasen doorloopt, betekent dit niet dat ingenieurs zich dogmatisch aan die fasen hoeven te houden. Idealiter is elk team verantwoordelijk voor "de linker- en rechterkant van de V", wat inhoudt dat elk team de mogelijkheid heeft om (gedetailleerde) specificaties te definiëren, iets te bouwen en validatie en verificatie op eigen niveau uit te voeren. Dit maakt een iteratieve manier van werken op elk niveau mogelijk. Terwijl het project zich door de V heen beweegt, beginnen verschillende, meer gespecialiseerde (en vaak meer mono-competentie) teams in iteraties aan het product te werken. Het Dual Vee-model combineert de mogelijkheid om in iteraties te werken met behoud van (budgettaire en kwaliteits)controle op projectniveau.
Het Dual Vee-model bevordert dus een 'shift-left'-aanpak, waarbij we proberen tests en verificatie dichter bij de te testen objecten en artefacten te brengen, klopt dat?
Het Dual Vee-model legt juist de nadruk op vroege tests, integraties en verificaties. De mogelijkheid om iteratief door de moeilijkheden van productontwikkeling heen te werken, versterkt het vermogen om projectrisico's te beheersen. Het is pijnlijk om op deze manier te werken, omdat het soms makkelijk is om een specificatiedocument te schrijven en het naar een ander team te gooien, om er maanden later achter te komen dat de specificaties verkeerd zijn geïnterpreteerd. Zou je liever één grote verrassing aan het einde van het project hebben (en de hoofdpijn van escalaties, brandjes blussen en paniek moeten doorstaan), of veel kleine verrassingen aan het einde van elke twee weken (en kleine hoofdpijntjes, beheersbare escalaties, beheersbare brandjes en frequente momenten van nervositeit)? Ik kies zonder twijfel voor het laatste.
Geweldig Ali, bedankt voor deze waardevolle inzichten. Nog één laatste vraag: Sinds Covid-19 hebben we allemaal gehoord over de zogenaamde rolling review-procedure, waarbij wettelijke eisen op een iteratieve en flexibele manier worden nageleefd en geverifieerd. Kun je daar iets meer over vertellen? Hoe ga je in de praktijk om met strenge wettelijke eisen zoals ISO 26262 voor functionele veiligheid bijvoorbeeld?
Rolling Reviews werden in 1994 door Sutherland en Schwaber beschreven als de "Sprint Review" en door Tom Gilb in Evolutionary Project Management (jaren 60) als "Evolutionary Delivery". Covid-19 dwong ons om meer met elkaar samen te werken (ontwerp/ontwikkeling en kwaliteitscontrole/verificatie). Iedereen zal het erover eens zijn dat een vergadering om de twee weken bijwonen veel meer inspanning vergt (en veel meer betrokkenheid en toewijding vereist) dan een maand vol speciale activiteiten aan het einde van een ontwikkelingscyclus van een jaar. Maar, zoals we in het Nederlands zeggen: "Nood breekt wet". Als we echt iets gedaan moeten krijgen, organiseren we een soort crisisruimte met een team dat over meerdere competenties beschikt. We geven ze de ondersteuning en bescherming die ze nodig hebben en we vertrouwen erop dat ze de klus klaren.
De ongemakkelijke boodschap hier is dat we, om echte wendbaarheid te bereiken, moeten samenwerken met alle competenties die nodig zijn om gekwalificeerde systemen te bouwen. Dat omvat ook nauwe samenwerking met veiligheidsmanagers en hun afgevaardigden. Als de plan-do-check-act-cyclus wordt teruggebracht tot twee weken, dan zouden activiteiten om te voldoen aan de eisen (functionele veiligheid) binnen die twee weken moeten vallen. Het is enorm waardevol om je deliverables stapsgewijs op te bouwen en continu semi-compliant te zijn. En bovendien… het geeft een goed gevoel om de controle te hebben!
Dit artikel werd oorspronkelijk gepubliceerd op: https://www.kegonacademy.com/de/wissen/blog/detail/elements-of-agile-in-hardware-and-physical-product-development