Der findes en særlig type optimisme, som ofte opstår, når et projekt er bagud, deadlines skrider, og stemningen langsomt begynder at blive anspændt. På et tidspunkt er der næsten altid nogen, der siger: “Vi skal bare have flere folk på.” Det lyder logisk. Hvis noget går for langsomt, må løsningen være flere hænder. Problemet er bare, at softwareudvikling og komplekse organisationer sjældent fungerer som et samlebånd.
Brooks beskrev det allerede i 1975. Når et softwareprojekt er forsinket, bliver det typisk endnu mere forsinket at tilføre flere mennesker. Ikke fordi folk er ineffektive, men fordi kompleksitet, koordinering, onboarding og afhængigheder vokser hurtigere end fremdriften. Nye mennesker skal forstå domænet, arkitekturen, historikken og alle de små uskrevne regler, som organisationen har samlet op gennem årene. Samtidig vokser antallet af møder, afklaringer og kommunikationsveje. Mange organisationer opdager derfor først for sent, at problemet sjældent var mangel på folk, men snarere mangel på flow.
Og det er egentlig dét, der er interessant.
For mange af de problemer organisationer kæmper med i dag, er ikke nye problemer. Vi har bare givet dem nye navne, nye processer og flere slides.
Goodhart beskrev allerede for årtier siden, hvorfor målinger mister værdi, når de bliver mål i sig selv. Det starter ofte med gode intentioner. Man vil skabe transparens, fokus og retning. Men så snart et tal bliver noget, medarbejdere eller teams bliver målt hårdt på, begynder adfærden stille og roligt at ændre sig. Pludselig handler det mindre om at skabe reel værdi og mere om at få tallene til at se rigtige ud. KPI’en bliver vigtigere end virkeligheden.
Conway beskrev noget lignende, bare på organisationsniveau. Han forklarede, at organisationer ender med at bygge software, der afspejler deres egne siloer og kommunikationsmønstre. Når teams arbejder isoleret fra hinanden, bliver systemerne ofte lige så fragmenterede. Når beslutninger skal igennem mange lag, opstår der tilsvarende flaskehalse i arkitekturen. Derfor handler mange tekniske problemer i virkeligheden mere om samarbejde og organisering end om teknologi.
Det samme mønster går igen i Parkinsons Lov, som beskriver hvordan arbejde udvider sig til den tid, man giver det. De fleste har oplevet møder, der varer en time, selvom beslutningen reelt var taget efter ti minutter. Eller projekter, hvor ekstra tid ikke nødvendigvis skaber bedre løsninger, men blot flere analyser, flere præsentationer og flere lag af koordinering. Tid skaber ofte friktion, og friktion skaber langsommelighed.
Murphy beskrev den side af virkeligheden, som alle kender, men som mange organisationer stadig opfører sig overraskede over. Ting går galt. Ikke nødvendigvis fordi folk er inkompetente, men fordi komplekse systemer altid vil fejle på et tidspunkt. Problemet er derfor sjældent selve fejlen. Problemet er organisationer, der ikke er forberedt på den. Når der ikke findes rollback-planer, observability, runbooks eller tydelige ansvarsområder, bliver små fejl hurtigt til store kriser.
Og så er der Hofstadter, som sandsynligvis har skrevet den mest præcise projektlov nogensinde: Alting tager længere tid end forventet, selv når man tager højde for Hofstadters Lov. De fleste projekter bliver nemlig først forstået rigtigt, mens de bliver bygget. Man opdager afhængigheder, edge cases og organisatoriske komplikationer undervejs. Derfor bliver planer ofte mere et udtryk for håb end for reel viden.
Det fascinerende ved alle de her love er ikke, at de eksisterer. Det fascinerende er, hvor præcist de stadig beskriver moderne organisationer, selvom mange af dem blev formuleret længe før AI, cloud-platforme, DevOps og digitale transformationer blev moderne buzzwords.
Hos Empiric ser vi de samme mønstre igen og igen på tværs af softwareudvikling, projekter, ledelse og organisationer. Mange virksomheder forsøger stadig at løse problemer med flere processer, flere statusmøder, flere governance-lag eller flere mennesker, selvom udfordringen ofte handler om noget helt andet. For mange ting i gang samtidig. For mange afhængigheder. For mange beslutninger, der skal opad i systemet. For meget organisatorisk friktion mellem idé og reel levering.
Det var også derfor vi lavede Kloge Åge’s Lovbog.
Bogen samler 15 klassiske love om softwareudvikling, projekter, ledelse og organisationer, men skrevet på en måde, der er genkendelig for mennesker, som faktisk arbejder med det i hverdagen. Ikke som tung managementteori, men som praktiske mønstre fra virkeligheden. Samtidig indeholder bogen en konkret facitliste med forslag til, hvad man faktisk kan gøre ved problemerne i praksis.
Ingen framework-religion. Ingen konsulent-sprog. Bare ting de fleste allerede har oplevet på egen krop.
