Af og til kommer ingeniørteams i problemer af mange forskellige årsager. Nogle gange bliver teamet overrasket af eksplosiv vækst. Eller også er vagtberedskabet kommet ud af kontrol med alarmer, der udløses hvert femte minut. Eller også er udviklings- og driftsteams simpelthen holdt op med at se hinanden i øjnene. Uanset årsagen er teamet i en dårlig situation, og der skal gøres noget for at løse det.
Hvis det er et nyt problem, er løsningen måske let: Tilføj et par flere servere, gå tilbage til en kendt god programversion eller saml alle sammen over pizza og øl for at få renset luften. Ofte sniger problemet sig dog ind på dig over tid, og pludselig er hullet så dybt, at du ikke kan finde vejen ud. På LinkedIn vil et team, der er nået til dette punkt, ofte erklære en tilstand, der er kendt som “Code Yellow.”
Yellow Alert
Nogle mennesker antager, at navnet Code Yellow er baseret på trafiklys, men mere præcist – og med en mere nørdet drejning – er det faktisk fra din yndlingsserie “Star Trek”. Mere præcist er det den måde, som besætningen på rumskibet Enterprise angiver deres aktuelle forsvarssituation. Uanset hvad, så er definitionen klar: Der er noget galt, og vi skal gå forsigtigt fremad. I overensstemmelse med begge metaforer har vi også en kode rød. Det kan bedre beskrives som en umiddelbar krise, hvor alle arbejder 24 timer i døgnet, indtil den er løst. Den gule kode er lidt mere afslappet: Det er alles primære fokus, men kun i arbejdstiden. Code Yellows har også en tendens til at vare i størrelsesordenen måneder, mens en Code Red bør vare i størrelsesordenen dage.
Andre virksomheder bruger måske et andet udtryk end Code Yellow, men effekten er den samme: Teamet kommunikerer til resten af virksomheden, at de har identificeret et alvorligt problem, som det er en prioritet at få løst for at sikre teamets og dermed virksomhedens succes. Evnen til at gøre dette er et vigtigt aspekt af åben og ærlig kommunikation, en værdi, der er afgørende for en sund kultur, og som ofte kan blive overset. At tale om vores problemer er lige så vigtigt, hvis ikke vigtigere, end at fejre vores succeser. Teams kan lære mere af at løse et problem, end de kan af en total succes.
Dette er ikke en fiasko
Det første skridt i starten af en Code Yellow er at forstå, at dette ikke er en fiasko. Der er ingen skam i at indrømme, at holdet har et problem, som skal løses. Fejl opstår, på trods af vores bedste bestræbelser på at undgå dem. Det eneste, vi kan gøre, er at diagnosticere problemet og afhjælpe det. Det eneste tidspunkt, hvor vi fejler, er, når vi vender det blinde øje til disse problemer. Dette gælder for den måde, hvorpå vores ingeniørteams interagerer med hinanden, lige så meget som det gælder for den software og de systemer, vi producerer og driver.
Det er dog afgørende, at de rigtige problemer bliver behandlet. Oftest er vi havnet i den nuværende situation på grund af en langsom kogning – stigende teknisk gæld, mange små problemer eller sammenbrud i en proces – som til sidst blev opbygget til en krise. Målet med Code Yellow skal være ikke kun at afhjælpe de nuværende problemer (en reaktiv komponent), men også at sikre, at de ikke gentages i fremtiden (den proaktive komponent).
Planlægning af en vellykket Code Yellow
Der er flere komponenter, der kræves for en vellykket Code Yellow, samt nødvendige brikker for at få tilslutning fra resten af organisationen:
- Problemformulering: Der skal være en klar og aftalt redegørelse for de problemer, som teamet står over for, og som har givet anledning til den gule kode. Dette bør ikke kun omfatte, hvad de aktuelle problemer er, men også hvad den aktuelle forståelse af deres grundlæggende årsag er.
- Afslutningskriterier: Dernæst skal du have specifikke mål, som teamet skal arbejde hen imod for at komme ud af den gule kode. Det skal være traditionelle SMART-mål: specifikke, målbare, opnåelige, relevante og tidsbestemte mål. Det er disse mål, der gør det muligt for teamet at gå ind i en gul kode i første omgang, da det dækker et fast omfang og ikke er tidsubegrænset.
- Kommunikation: Alle oplysninger om den gule kode, herunder bekendtgørelsen (som omfatter problemformuleringen og udgangskriterierne), den vellykkede afslutning og periodiske statusopdateringer bør sendes til den større organisation. Dette kan være din afdeling, eller det kan være hele den tekniske organisation. Det kan endda være hele virksomheden, afhængigt af problemets art.
- Projektledelse: Som i alle store projekter skal der være nogen, der er ansvarlig for at organisere arbejdet og formidle oplysninger. Da det drejer sig om et scenarie med “alle mand på dæk” for det berørte team, er det normalt nyttigt at have en dedikeret projektleder (PM) til at hjælpe med dette. Dette er typisk en projektleder, der har viden om teamet og arbejdet, men som ikke er direkte involveret i udførelsen. Dette frigør lederne og de enkelte bidragydere til at fokusere på det aktuelle arbejde.
Når hvert af disse aspekter er blevet overvejet, og beslutningen er truffet om at gå ind i Gul kode, er teamets første handling at reorganisere deres prioriteter omkring exitkriterierne. Dette betyder ofte, at de kvartalsvise mål skal lægges på hylden. Det kan også være nødvendigt at etablere et dedikeret møde omkring drøftelse af status for exitkriterierne.
Rum til at trække vejret
Det er fint nok for et team at gå ind i Kode Gul og arbejde med et enkelt fokus på de mål, der er sat for at rette op på tingene, men det er ikke nok til, at teamet får succes. For at opnå sand succes skal alle omkring holdet forstå situationen og give dem plads til at udføre deres arbejde. Det er her, at en sund ingeniørkultur rejser sig for at tage udfordringen op.
- Forvent forsinkelser: Den mest almindelige måde, hvorpå et tangentielt team vil blive påvirket, er gennem forsinkelser. De må forvente, at alle anmodninger, der er blevet fremsat til det påvirkede team, kan blive forsinket, hvis de ikke ligger inden for rammerne af exitkriterierne. Den gule kode indebærer i sin kerne en omlægning af prioriteterne for at løse det angivne problem. Eksterne teams skal tage højde for dette og forstå, at deres egne projekttidsplaner muligvis skal justeres.
- Minimer nye anmodninger: Andre teams bør også afholde sig fra at bede det berørte team om nye ting, der ligger uden for rammerne af de definerede exitkriterier. Ved at minimere disse anmodninger, ud over at acceptere forsinkelser på eksisterende anmodninger, kan det berørte team bruge sine begrænsede tekniske timer på at komme til den anden side af den gule kode.
- Anmodninger om assistance fra andre teams: Holdet i Code Yellow kan finde ud af, at de har brug for hjælp udefra for at nå deres mål. Hvis der f.eks. er en pludselig, eksplosiv vækst i trafikken, kan de have brug for at fremskynde tilvejebringelsen af ny hardware. Det kan være nødvendigt at ændre sine egne prioriteter, hvis man befinder sig på den anden side af en sådan anmodning. Husk altid, at teamet alle er en del af den samme virksomhed, og som sådan lykkes eller fejler alle sammen.
Ingeniørteams står sjældent alene, og det er vigtigt, at alle forstår værdien af, at disse teams fungerer godt og arbejder godt sammen. En lille midlertidig forsinkelse af målene for at sikre, at dette er tilfældet, er det hele værd.
Lys for enden af tunnelen
Code Yellow repræsenterer en betydelig mængde højt prioriteret arbejde, og det vil ofte være stressende for teamet at arbejde sig igennem det. Det er svært at sige “nej” til kolleger, der fremsætter en rimelig anmodning, og det arbejde, der er i omfanget, indebærer sjældent, at der bruges tid på interessante nye funktioner. Hvis de problemer, der skal løses, omfatter kommunikationsproblemer mellem grupper, vil der desuden være nogle vanskelige samtaler, der skal føres. Men efterhånden som teamet nærmer sig afslutningen af arbejdet, vil det være meget lettere at gennemskue, hvad der ligger på den anden side af exitkriterierne.
Det ultimative mål med Code Yellow er at få teamet ud af en reaktiv tilstand, hvor de løber fra krise til krise, og ind i en proaktiv tilstand, hvor de er i stand til at arbejde på de rigtige store projekter. Opnåelse af exitkriterierne vil betyde, at ingeniørerne er mere effektive og i stand til at arbejde proaktivt. Dette er et stærkere team – ingeniørerne er gladere, fordi de ikke er under et stort stress af driftsarbejde, teamet fungerer godt, fordi de taler effektivt med hinanden, og kunderne er tilfredse, fordi anmodninger håndteres enten gennem automatisering eller inden for en rimelig tid.
Har din virksomhed en intern proces, der svarer til, hvordan LinkedIn laver en Code Yellow?
– Todd Palino