När jag presenterade på Stockholm Agile for Hardware-träffen nyligen blev det tydligt att det finns ett växande intresse för att ta agila principer bortom mjukvaruvärlden. Men det blev också tydligt att det finns en utbredd missuppfattning om vad det innebär. Många tänker fortfarande på agilt som synonymt med snabbhet, med att släppa tidigt och ofta, med att iterera sig fram. Och i mjukvara fungerar det. Men hårdvara har sina egna sanningar, och om vi ska vara ärliga mot det agila tänkandet måste vi börja med att respektera dem.
En kretskortslayout kan inte ångras med en git revert. En gjutform som kostar hundratusentals kronor kan inte itereras bort. Leveranskedjor har ledtider som mäts i månader, inte minuter. Det är lätt att avfärda dessa begränsningar som ursäkter för att inte förändras, men det vore intellektuellt ohederligt. De är verkliga, och de ställer krav på oss att vara mer genomtänkta i hur vi tillämpar agila principer — inte att överge dem.
SAFe for Hardware erbjuder en struktur för att navigera den här komplexiteten, och jag tycker att det finns mycket gott i det. Det ger hårdvaruteam ett gemensamt språk och en rytm för planering och synkronisering. Men ramverket i sig är inte poängen. Poängen är insikten att även i en värld av fysiska begränsningar kan vi arbeta med kortare feedbackloopar, tydligare prioriteringar och bättre kommunikation mellan discipliner. Det handlar inte om att göra hårdvaruutveckling snabb — det handlar om att göra den medveten.
Att förstå sina begränsningar
Det jag försökte förmedla i min presentation var att agilt i grunden handlar om att förstå sina begränsningar och optimera inom dem. I mjukvara är de flesta begränsningar kognitiva och organisatoriska. I hårdvara är de dessutom fysiska och ekonomiska. Det gör att cykeltiderna ser annorlunda ut, att riskerna har en annan karaktär och att kostnaden för att ha fel är högre. Men just därför behöver vi de agila principerna ännu mer. Inte för att gå snabbare, utan för att fatta bättre beslut med den information vi har.
En sak som slog mig under samtalen efter presentationen var hur många hårdvaruingenjörer som kände igen sig i problembeskrivningen men aldrig hade fått verktygen att hantera den. De hade upplevt de långa väntetiderna, den bristande kommunikationen mellan mekanik, elektronik och mjukvara, känslan av att beslut fattades för sent eller för långt bort. Det agila tänkandet ger dem inte en magisk lösning, men det ger dem ett sätt att prata om problemen och, viktigare, ett sätt att börja förändra dem.
Det finns en ödmjukhet i att erkänna att vi inte kan behandla hårdvara som mjukvara. Men det finns också en styrka i att inse att de grundläggande principerna — synliggör arbete, begränsa pågående arbete, sök feedback tidigt, respektera människors kompetens — gäller oavsett vad vi bygger. Resan mot agil hårdvaruutveckling handlar mindre om att adoptera ett ramverk och mer om att förändra hur vi tänker om samarbete, risk och lärande. Det är en långsammare resa än i mjukvaruvärlden. Men den är inte mindre viktig.