Om du har arbetat med eller varit i närheten av mjukvaruutvecklare under det senaste decenniet har du förmodligen hört talas om Agile-metoden. Agile utformades ursprungligen för att hjälpa utvecklare att skapa mjukvara av högre kvalitet, snabbare och mer tillförlitligt.
Men Agile är inte längre bara för mjukvara: När programvaruteam upplevde betydande förbättringar i hastighet, kvalitet och tillförlitlighet genom att använda den agila metoden började team på andra avdelningar införa agila metoder i hopp om att få liknande resultat. Idag används den agila metoden i hela företag, av team inom marknadsföring, försäljning, kundframgång, verksamhet och andra områden, för att främja produktivitet, hållbarhet, flexibilitet och öppenhet.
- Individuals and interactions over processes and tools
- Fungerande programvara framför omfattande dokumentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Även om dessa värderingar var avsedda att gälla specifikt för programvaruutvecklingsteam kan principerna bakom dem verkligen tillämpas på team inom alla discipliner. Låt oss fördjupa oss i vart och ett av dessa värden och hur de fungerar i verkligheten.
Individer och interaktioner framför processer och verktyg
I slutet av 1990-talet stod det klart att traditionella metoder för mjukvaruutveckling inte var tillräckligt snabba eller anpassningsbara för att effektivt hantera arbetsflöden i utvecklingsteam. De flesta av dessa metoder var besvärliga, överreglerade och mycket mikrostyrda - vilket skapade dåliga miljöer för att inspirera till innovation och utveckling.
I slutändan saknade dessa metoder den flexibilitet, smidighet, skalbarhet och öppenhet som modern mjukvaruutveckling kräver. De flesta av dem krävde omfattande utbildning för att komma igång, och för att utöva dem krävdes mycket tid, kunskap och ansträngning. Ofta blir grupperna så uppslukade av de processer, verktyg, regler och roller som metodiken föreskriver att de tappar bort sina egentliga mål ur sikte.
Den agila metoden betonar effektivt, kommunikativt samarbete mellan kompetenta människor framför alltför komplexa processer och verktyg. Många av metoderna före Agile var starkt beroende av ceremonin och disciplinen i ett mycket reglerat arbetsflödeshanteringssystem för att behålla kontrollen över människor. Det är inte bara besvärligt, det är också hemskt för moralen. Människor trivs sällan i miljöer där de inte har något utrymme för experimenterande, kreativitet eller självständighet.
Oavsett vilken bransch du arbetar är det viktigt att komma ihåg att det är människorna i din organisation som gör den storartad. Att ge smarta människor möjlighet att göra ett bra arbete är en mycket smartare långsiktig strategi än att försöka behålla kontrollen genom omfattande och komplexa ledningssystem.
Agile-metodiken är medveten om detta och värdesätter effektivt samarbete mellan människor, och processer och verktyg är endast till för att stödja detta samarbete.
Fungerande programvara med omfattande dokumentation
I början av programvaruutvecklingen utvecklades och släpptes programvaran i stora partier, vilket gjorde utvecklingscyklerna långsamma och komplexa. De rådande metoderna före Agile krävde ofta att teamet skulle skapa omfattande dokumentation för allt de gjorde, som ett sätt att säkra mjukvarans kvalitet och hållbarhet. Denna dokumentation var nödvändig för att hålla ordning på all information som fanns i en iteration.
En viktig del av Agile är frekvent, iterativ utveckling - planering och produktion av arbete i små omgångar och sedan testning av arbetet på marknaden. Den agila metoden värdesätter därför fungerande programvara - programvara som kan levereras till marknaden - högre än omfattande dokumentation. Agilt tänkande är att bra dokumentation är användbar för att hjälpa människor att förstå hur en programvara byggdes och hur den ska användas, men i slutändan är syftet med utveckling att skapa programvara (eller inom andra discipliner: en funktionell produkt eller tjänst), inte dokumentation.
Vad händer om du inte arbetar med mjukvara? Denna princip - att iterera ofta och sträva efter att släppa funktionella projekt - kan fortfarande tillämpas. Om du släpper ut idéer, projekt och produkter på marknaden ofta kan du göra små justeringar innan de blir stora problem. Du behöver ingen omfattande dokumentation eftersom det du släpper inte är lika komplext. Oavsett vilket område du arbetar inom är det alltid en smart idé att värdera att få det gjort framför att få det gjort perfekt (oavsett hur långsamt).
Samarbete med kunderna i stället för avtalsförhandlingar
Traditionellt sett arbetade utvecklingsteamen tillsammans med kunderna i förväg för att ta fram ett kontrakt som uppfyllde de behov som uttrycktes vid tidpunkten för skrivandet. Problemet med detta tillvägagångssätt är att det inte gav något utrymme för samarbete efter att kontraktet undertecknats - teamen levererade programvara som uppfyllde de behov som uttrycktes i kontraktet, inte nödvändigtvis behov som verkligen återspeglades i verkligheten.
Utvecklarna började inse att det inte spelar någon roll om ett projekt uppfyller behoven i kontraktet om det inte verkligen uppfyller kundens behov när det levereras. För att se till att teamen skapar arbete som faktiskt behövs på marknaden, involverar den agila metoden kundens röst i produktutvecklingen. Företaget värdesätter aktivt och ofta samarbete med kunderna för att utveckla arbete som verkligen tillgodoser verkliga behov.
Även om ditt arbete inte kräver omfattande avtal med dina kunder kan du ändå dra nytta av den här idén: Du kan dra nytta av denna idé: Samarbeta med dina kunder under hela utvecklingsprocessen, inte bara i början. Be om deras feedback. Inkludera deras idéer i din design. Låt deras idéer påverka ditt sätt att arbeta. Aktivt och frekvent samarbete med kunderna leder till högre kvalitet och mer innovativa lösningar för att möta deras behov.
Att reagera på förändringar och följa en plan
Om ditt företag arbetar i långa utvecklingscykler, med mycket planering i förväg och strikt föreskrivna tidsramar för varje arbetsfas, vet du att det finns väldigt lite utrymme för att anpassa sig till förändringar. Du skapar en stram plan med en stram budget och du måste hålla dig till den, till varje pris.
Problemet med den här typen av arbetsflödeshantering är att grupper sällan beter sig i verkligheten som de gör på papper. Även med de mest datadrivna uppskattningarna kan teamen inte alltid leverera arbetet enligt ett specifikt schema. Förändringar på marknaden, i teamet, i data eller i kraven kan drastiskt påverka framstegen i ett arbete. För att inte tala om det faktum att man ofta måste hålla sig till planen till varje pris för att ignorera värdefull information och insikter från marknaden.
Programvaruutvecklare insåg att de behövde ett system för hantering av arbetsflöden som skulle ge dem möjlighet att anpassa sig till dessa typer av förändringar. Den agila metoden gör det möjligt för team att leverera i små partier, ofta, med korta planeringscykler - så att teamet kan förändras när planerna ändras.
Detta värde är relevant inom alla områden, oavsett om du planerar en lansering av en mjukvaruprodukt, en marknadsföringskampanj eller ett forskningsprojekt för försäljning: Försök inte äta elefanten på en gång. Som ordspråket säger är det bästa sättet att ta itu med ett stort problem att göra det en bit i taget. Den agila metoden uppmuntrar team att dela upp stora, komplexa initiativ i små, hanterbara delar för att maximera flexibilitet, anpassningsförmåga och kreativitet.
Läs mer
Är du redo att komma igång med den agila metoden? Vi rekommenderar att du tittar på detta webbseminarium eller läser denna sida för att få mer information.
