Projekt är väldigt vanligt i många organisationer som utvecklar mjukvara. Tyvärr tar man sällan hänsyn till vilken skada projektet kan medföra i organisationen och för den produkt man utvecklar.
När jag som Agil coach träffar olika företag och diskuterar hur deras projekt påverkas av att organisationen blir en agil leveransorganisation, slås jag av att vi ofta har fel fokus. Vi ser bara till projektets perspektiv och inte på hur projektet relaterar till resten av organisationen.
Vad händer när vi enbart ser till hinder för själva projektet?
Sett ur ett större perspektiv, där ett projekt är en tillfällig insats, kommer den totala livscykeln för de produkter och funktioner projektet skapar att påverkas. Den lokala optimeringen i tid och rum skapar en isolerad ö som ligger i ett stort, öppet hav av kontinuerliga förändringar. Havet kommer att påverkas under lång tid av de beslut som projektet fattar i sin bubbla.
Riskanalysen – Ett exempel på vårt missriktade fokus
Ett klassiskt projekt, oavsett om det drivs med en vattenfallsmetodik eller en agil metodik, har vanligtvis en eller ett par initiala övningar för att identifiera risker i projektet. Syftet är att veta mer om vad som kan stjälpa projektet och därmed kunna navigera i en komplex omgivning för att kunna undvika eller åtminstone hantera riskerna. Problemet är att frågeställningen ofta hanterar just hur projektet ska komma i mål och uppfylla beställarens behov, budget och tidplan.
Vad skulle hända om vi i våra riskanalyser skulle ställa oss följande frågor?
- Fokuserar vi på användarnas allra viktigaste behov eller inför vi en stor mängd funktioner som inte tillför signifikant värde? Vilka onödiga funktioner, och därmed underhåll, skapar vi? Hur validerad vi under projektets gång att våra hypoteser om vad som är viktigast är giltiga?
- Vilka konsekvenser skapas när vi väljer att köra projekt mot fasta datum utan att förändra omfattningen efter vad som faktiskt mäktas med? Vad händer med våra krav på långsiktig kvalitet, refaktorering samt automatisering av tester?
- Vilka begränsningar skapar projektet för kompetensspridning i och omkring teamen? Vilka långsiktiga konsekvenser och kostnader medför det att inte fokusera på lärandet mellan individer?
Till det kan även läggas frågor som rör projektens leveransplan där många projekt, även om de körs agilt, har alldeles för lång feedbackloop. Som exempel kan vi fundera på följande:
- Vilka felaktiga beslut fattar vi pga för låg kunskap om användarbehov och teknik, om vi inte skapar små, värdeskapande delreleaser i ett väldigt tidigt skede? Vilka onödiga kostnader medför det?
- Vilka verkliga hinder har vi för att lära oss så tidigt som möjligt och därmed maximera lärande? Vad är kostnaden att inte fokusera på tidigt och kontinuerligt lärande?
- Vilka förlorade intäkter har företaget pga oförmågan att få ut delvärden?
- Vilken kostnad har företaget för den allt för långa omställningstiden mellan olika initiativ och oförmågan till att vara agil?
Projektet blir ett plåster för en ickefungerande organisation
Projekten medför stora risker och konsekvenser som vi väljer att blunda för. Om vi verkligen är rädda om våra kunder, produkter och företagets välmående bör vi överväga om projektet är det bästa sättet att leverera värde på eller om det bara är ett plåster på en ickefungerande organisation där “affär och IT” inte samverkar smidigt och gamla styrprocesser förhindrar en effektiv affärsutveckling.
Vad är alternativet?
Allt fler organisationer inser värdet av att identifiera flöden av funktioner och organiserar sig så att dessa kan hanteras av en stabil utvecklingsorganisation med team som får utrymmet att bli högpresterande och hantera produkten över tid. Vi bygger en miljö där människor samarbetar för att kontinuerligt skapa nytta istället för att bygga tillfälliga strukturer som förhindrar effektivitet.
Några råd för att utveckla en organisations som lyckas leverera mjukvara löpande:
- Fokusera på korta feedbackloopar genom frekventa och värdeskapande leveranser till verkliga användare. Passa på att bygg en förmåga till kontinuerligt värdeskapande i organisationen och se till behoven i organisationen efter projektet är slut.
- Ge utvecklingsteamen förutsättningar för att skapa hållbara och högkvalitativa produkter genom kontinuerligt lärande, refaktorisering, automatiserad testning och inte minst kompetensöverföring.
- Skapa förutsättningar där medlemmarna i teamen kan samarbeta med behovsägare för att skapa bra lösningar, hela tiden.
Ta gärna kontakt och berätta om din erfarenhet av projekt!
—
Håkan Appelgren är konsult med stor erfarenhet av lean och agil utveckling. Med en grund inom utveckling och projektledning har han med stor framgång arbetat som Agil Coach och utvecklingschef och hjälpt små och stora organisationer att implementera och förfina agila arbetsmetoder och skala utvecklingen. Han är även en uppskattad utbildare och workshopledare. Läs mer »