Hur kan vi skapa tillförlitliga prognoser inom mjukvaruutveckling - med tanke på att det vi gör är komplext? Två saker som är nödvändiga är:
Ett stabilt system
Korrekt data
Jag återkommer till detta, men först ska jag förklara skillnaden på komplicerat och komplext.
Komplexitet
När vi säger att något är komplicerat pratar vi om huruvida någonting är enkelt att förstå. En klocka, exempelvis, är ganska komplicerad. Det är inte jätteenkelt att konstruera en klocka själv. Däremot är en klocka förhoppningsvis förutsägbar.
Komplexitet å andra sidan hänvisar till hur något beter sig. En tärning, till exempel, som är ganska enkel att förstå och tillverka, beter sig väldigt oförutsägbart. Den är alltså komplex, men inte komplicerad.
Cynefin-ramverket
Dave Snowden beskriver Cynefin-ramverket som ett "sense making" ramverk. Det delar in domäner i olika grader av komplexitet, och är tänkt som ett hjälpmedel för att förstå den kontext man befinner sig i och låta det ledsaga hur man agerar, fattar beslut och leder.
Man kan befinna sig i flera domäner samtidigt, beroende på vilken aspekt av ett problem man tittar på. Det är också möjligt att flytta sig mellan domäner över tid. Detta sker då oftast medurs.
Hur är detta kopplat till förutsägbar mjukvaruutveckling då? Vi befinner oss till mångt och mycket i den komplexa domänen. Företagskultur är ett exempel på ett komplext system.
Hur är det med kodbasen? Man skulle kunna argumentera för att den är komplicerad snarare än komplex. Okej, visst, men den som någon gång jobbat i en stor legacy produkt är nog böjd att hålla med om att den kan vara snudd på komplex den också.
Det betyder att vi behöver strategier och tankesätt som är anpassade till den komplexa verkligheten vi befinner oss i.
Förutsägbarhet
I ett komplext system finns inga tydliga kopplingar mellan orsak och verkan. Det är i princip omöjligt att analysera sig fram till när något kommer vara klart. Istället måste vi hitta andra sätt att skapa prognoser.
Stabilt system
Det första vi behöver för tillförlitliga prognoser är ett stabilt system. Vad betyder det?
I ett stabilt system matchar inflödet av arbete systemets kapacitet.
När inflödet överstiger kapaciteten uppstår turbulens. Det skapas köer, ledtider ökar och vi genererar teknisk skuld. Det omöjliggör kort sagt alla försök att vara förutsägbar.
Systemet kan stabilisera sig igen med nya parametrar. Men då oftast i ett mindre förutsägbart läge.
Stabila team
Jag nämnde tidigare att företagskultur är ett exempel på ett komplext system. Ett annat exempel är team. Det betyder att stabila system kräver stabila team.
Det betyder inte att man aldrig ändrar team-komposition, eller att man är fast för evigt i samma team. Däremot ska man inte ändra team utan eftertanke eller för ofta.
Korrekt data
Den andra ingrediensen i förutsägbarhet är korrekt data.
Psykologisk trygghet
Hur får vi då korrekt data? Till att börja med, och detta oberoende av domän egentligen, är psykologisk trygghet. Om medarbetare inte känner sig bekväma med att öppet dela med sig av sina åsikter och tankar kommer du aldrig ha korrekt data.
Whenever there is fear, you will get wrong figures.
- W. Edwards Deming
Det behöver inte vara på nivån att man blir utskälld eller utsatt för represalier när man uttalar sig. Om man blir ignorerad, avfärdad eller avvisad så kommer förtroendet för organisationen sakteliga gröpas ut, och man kommer börja ta det säkra före det osäkra och sluta engagera sig.
Opartiskhet
Den andra pusselbiten är opartiskhet.
I ett experiment, och jag återger det med egna ord, tillfrågades en grupp om dom trodde det högsta trädet i världen är högre eller lägre än 50 meter. De flesta svarade "högre". Nästa fråga lydde: "Hur högt?" och man gav svar på i snitt lite högre än 50 meter.
En annan grupp fick frågan om dom trodde att världens högsta träd är högre eller lägre än 150 meter. "Lägre" svarade de flesta. På följdfrågan svarade man i snitt något lägre än 150 meter - men väldigt skilda svar från den första gruppen.
Vi påverkas, undermedvetet, av information och data vi tar del av.
Kombinerar vi brist på psykologisk trygghet med brist på opartiskhet är det enda vi säkert kommer veta är att vi inte är förutsägbara.
Lösning
Vi vet att vi befinner oss i den komplexa domänen, och att vi behöver ett stabilt system och korrekt data. Vad kan vi göra?
Skilj på estimat och prognoser
Till att börja med så skilj på estimat och prognoser. Använd relativa storleksbaserade estimat och härled kalendertid baserat på empiriskt data.
Fråga inte när någonting kommer vara klart, eller hur lång tid det kommer att ta. Beräkna varaktighet baserat på tidigare hastighet - på empiriskt data.
Arbeta iterativt och inkrementellt
Det går, som sagt, att flytta sig mellan domäner i Cynefin-ramverket. Det här utnyttjar vi när vi arbetar i iterationer. Notera dock att det inte är tillräckligt att jobba i iterationer. Man måste också arbeta iterativt och inkrementellt.
Att arbeta i iterationer betyder inte nödvändigtvis att man arbetar vare sig iterativt eller inkrementellt.
När vi arbetar iterativt förfinar vi någonting över tid, i varje iteration. När vi arbetar inkrementellt lägger vi till mer och mer funktionalitet över tid. Inom mjukvaruutveckling vill vi jobba både iterativt och inkrementellt - samtidigt.
När vi bryter ner vårt stora komplexa projekt i iterationer kan vi ofta betrakta en enskild iteration som komplicerad snarare än komplex. Vi låter våra experter - teamen - analysera innehållet i iterationen och komma fram till möjliga lösningar och estimat.
Kanske bryter teamet ner arbetet ytterligare, och varje nedbruten uppgift kanske till och med kan anses vara ett enkelt problem - tydligt för alla inblandade hur det ska lösas.
80/20 regeln
När vi arbetar iterativt och inkrementellt kan vi också fatta affärsbeslut kring vad som ska levereras och när något är "bra nog". I ett komplext system så är det mer relevant att formulera ett mål än att lista alla krav, och i slutändan är det viktigaste att målet uppfylls.
Många gånger är målet uppfyllt utan att alla krav för den sakens skull är implementerade. Andra gånger tillkommer nya krav längs resans gång.
Att fokusera på målet istället för enskilda krav är jätteviktigt för att lyckas vara förutsägbara.
Avslutningsvis
Varför är vi ofta så dåliga på att förutsäga utvecklingsprojekt då?
Förutom en uppenbar brist på psykologisk trygghet i många organisationer, så tror jag många agerar under antagandet att man befinner sig i den enkla domänen. Då tror man att man kan kontrollera systemet centralt med hjälp av Excel, Gantt-scheman och resursallokering.
Om antagandet dock inte stämmer (och det gör det inte) så kommer det inte att fungera. Antagligen har man inte heller några strategier för att arbeta med ett komplext system.
Risken är då att man faller över kanten in i kaos - det som i Cynefin kallas "zone of complacency" (ungefärligt översatt självgodhets-zonen). Det är här hjältar föds. Fel sorters hjältar. För att stabilisera det kaos som uppstår behöver man starka individer som inte räds att kliva andra på fötterna, och som inte bryr sig om långsiktiga konsekvenser av sitt agerande.
Detta underminerar dock ett stabilt system, och det underminerar psykologisk trygghet. Nästa gång blir det ännu svårare att vara förutsägbar.
Så vad ni än gör, fall inte över kanten.
Comments