AMP - Ett avslut med en ny början

Jag började min AMP resa cirka 18 månader sedan med detta blogginlägg. Ambitionen var att försöka sätta ihop en ny modell för att bedöma företags och teams tekniska mognad, i syfte att i bästa fall förbättra Omegapoints bedömningar, sprida kunskapen om vad vi bedömer inom företaget och själv bli väldigt bra på att genomföra sådana granskningar.

Under resans gång har jag lärt mig mycket:

  • Att mognadsbedömning är ett sämre ord än förmågeuppskattning - det känns som en mer positiv upplevelse för den granskade.

  • Att det går att balansera ett tidvis intensivt uppdrag, ett kompetensutvecklingsprogram och bröllopsplanering. Det är bara väldigt svårt och man måste lära sig att säga nej.

  • Att man bör optimera för att minska ledtiden för arbete från idé till produktion

  • Att ovanstående mätvärde lider av att allokera alla resurser (såsom i människor) till 100%, gör mindre och få ut mer är det något motsägelsefulla mantrat

  • Att om man har en grupp som godkänner releaser så går det långsammare att få ut i produktion men man får ingen höjd kvalitet i utbyte, den blir snarare ofta lidande

  • Samt en väldans massa mer om DevOps-rörelsen, säkerhet, team, process och organisation

Jag har gjort min “mognadsmodell” eller förmågemodell som den fick heta till slut. Den är inte perfekt än och under AMP har antalet förmågor fluktuerat mellan ett tjugotal och ett hundratal till att till slut landa på en kanske något hög siffra om 29 förmågor man som IT-organisation bör tillskansa sig i liten eller stor omfattning för att kunna leverera värde ofta, snabbt och säkert. Modellen har provkörts på tre intet ont anande kollegor i intervjuformat och tog i anspråk mellan tre och sex timmar. Modellen har på så vis gått igenom ett par iterationer och hamnat på en nivå där jag själv tycker den är ganska bra. Helst vill jag ju att den skulle vara perfekt vid det här laget, men det behövs nog ännu ett par iterationer internt innan jag vill släppa lös den i det vilda.

Modellen i sig blev av kvalitativ typ. En mer kvantitativ modell hade behövt vara mer deterministisk, med många tydliga frågor så att man kunde beräkna en slutgiltig poäng över hur bra en organisation är. Jag var länge nere i den fällan att jag ville få det att fungera, men verkligheten är lite för komplex. Vilka förmågor en organisation behöver beror på bransch, vilken lagstiftning man lyder under och i vilken fas bolaget är i (exvis startup, scaleup, established). En kvantitativ modell skulle nog kunna ha sin plats, man vill ju gärna kunna mäta sig och jämföra med andra, men det kräver väldigt mycket utveckling och underhåll. Istället blir det intervjuformat där frågeställaren får använda sin erfarenhet för att borra djupare i svaga delar och sålla bort det som är irrelevant för just denna kund. Efter det får kunden tips om vilka förmågor man borde satsa på härnäst tillsammans med förslag på hur man kan mäta hur väl man uppfyller just den förmågan. Kunden får då ett verktyg för att benchmarka mot sig själv istället, som jag tror blir mycket mer givande och relevant.

Nu när AMP snart är färdigt hoppas jag kunna fortsätta utveckla min förmågemodell samt få nya och gamla förmågor att bidra till den så att den slutar vara “Adams modell” och börjar bli något hela bolaget kan stå bakom.

Föregående
Föregående


AMP: Högintensiv träning för en tech lead wannabe

Nästa
Nästa

AMP med fokus på Compliance-as-Code