Året var 2001. Sjutton mjukvaruutvecklare samlades på Snowbird skidort i Utah för att åka skidor, nätverka och diskutera sätt att förbättra vad som hittills hade varit standardprocesser för mjukvaruutveckling.
De som snart skulle bli grundare av agil utveckling var trötta på de sena leveranser, överskridna budgetar och otillfredsställda kunder som då definierade situationen när det gällde att leverera storskaliga, komplexa mjukvaruprojekt. De visste att det måste finnas ett bättre sätt att göra saker och ting, och de hade rätt!
Efter ett intensivt tredagarsmöte fastställde gruppen vad de ansåg vara de viktigaste riktlinjerna för mjukvaruutveckling. I dokumentet beskrivs de fyra kärnvärdena och tolv principerna för agil utveckling. De kallade dokumentet för Manifesto for Agile Development - och vårt sätt att "göra saker" har aldrig varit detsamma sedan dess.
Övergången till agilitet är dock inte alltid lätt. Det kräver en enorm förändring av tankesättet, och människor gillar inte att ändra sitt sätt att göra saker och ting. Man måste lära sig nya processer och verktyg och grupperna omstruktureras ofta för att ta bort silos och möjliggöra tvärfunktionell kapacitet. Dessutom är vissa team rädda för att den snabbhet och flexibilitet som agilitet innebär inte är förenlig med den typ av projekt som de arbetar med.
Särskilt djupt tekniskt orienterade IT-team som implementerar verksamhetskritiska plattformar och upprätthåller viktiga produkttillgänglighetstider kan vara försiktiga med att göra stora förändringar i hur de gör saker och ting. Och det på goda grunder - om de gör misstag från deras sida utsätter de företaget för stora affärsrisker och de kostnader som är förknippade med dem.
Ändå lyckas innovativa IT-team med agila - och skördar operativa fördelar som ökad snabbhet och ökat engagemang bland medarbetarna. Deras långsamma och stabila inställning till övergången och deras vilja att hitta kreativa sätt att anpassa sig till agilitet vinner dagen.
Kom ihåg att agilitet i slutändan bara är en lös uppsättning värderingar och principer som är öppna för tolkning. Det handlar om att skapa en grund för tillit, anpassningsförmåga, ägarskap och samarbete i det sätt ni gör saker och ting.
Låt oss ta en snabb titt på de agila kärnvärdena 4 och se hur de passar in i ett IT-team.
Att reagera på förändringar i stället för att följa en plan
Det betyder inte att en plan är dålig - det finns inget sätt för ett IT-team att införa en tung finansiell IT-infrastruktur utan att först planera. Det betyder bara att förändringarna är ständiga och att planen inte bör vara huggen i sten. Ett agilt IT-team som arbetar i sprintar är mycket lyhört för förändringar. Nya funktioner kan läggas till i nästa sprint och prioriteringarna kan lätt flyttas mellan dem.
Leverera fungerande programvara - inte dokumentation
Standardhantering i vattenfall kräver en hel del dokumentation. Det behövs tekniska kravspecifikationer, testplaner, konstruktionsdokument och alla godkännanden som hör till dem. Problemet är att alltför mycket dyrbar tid går åt till att skriva och utforma dessa dokument i stället för att iterera och testa produkten. Agila IT-team fokuserar på att leverera snabba iterationer och sedan testa dem så att eventuella fel eller problem identifieras och hanteras omedelbart.
Fokus på individer och interaktioner, inte på verktyg och processer.
Talangfulla människor bygger inte bara produkter utan upprätthåller också goda relationer med kunderna. Utvecklingen bör vara personaldriven, eftersom det är människor som svarar på verksamhetens behov, förstår kundernas problem och driver utvecklingsprocessen. Verktyg och processer är användbara eftersom de bidrar till effektiviseringar, men om du inte har begåvade, människoorienterade personer kan inte ens den bästa processen eller tekniken i världen hjälpa dig. Ett agilt IT-team strävar efter att ha anställda av högsta kaliber, med flera olika kompetenser för att säkerställa välfungerande tvärfunktionella team.
Samarbete med kunderna är inne, att förhandla med dem är ute.
Ett agilt IT-team förhandlar inte om detaljerna i en leverans med sina kunder. Agila IT-team samarbetar snarare med sina kunder under hela utvecklingsprocessen. På så sätt kan kunderna bli en del av teamet och ge feedback om framstegen när de implementeras. Att förhandla om produktkrav med kunderna skapar ett motsatt förhållande - definitivt inte något som ett agilt IT-team vill ha.
Clarizenhjälper dig att förenkla arbetet och uppnå dina mål. Planview AdaptiveWorks skalbara lösningar ger teamet verktygen för att nå framgång, från strategi och planering till arbetshantering och genomförande.
