Om ni inte redan har anammat agila arbetssätt på ditt jobb så lär ni göra det snart. Agila metoder är i dag närmast att betrakta som normen för systemutveckling.

Som vanligt när många tar till sig nya metoder för att göra något på kort tid så blir det en del missförstånd. Här berättar Infoworld om 15 sätt att utföra agilt arbete på dåliga sätt.

1. Gör agilt i stället för att vara agil

Det viktigaste med att jobba agilt är att börja med att vara agil, inte med att göra agila saker. Det handlar om att anta en ny mental färdriktning. Använd den filosofi som beskrivs i det agila manifestet. Läs igenom det noggrant. Ordvalen i det är inte slumpmässiga. Och kom i håg, det finns ingen agil standardmetod eller standardprocess. Att vara agila är att vara flexibel och att ständigt förbättra sig, inte att låsa sig vid ett visst sätt att göra saker.

Läs också: Trots kompetensbrist är det svårt att komma in i it-branschen. Är företagen för fega?

2. Ser poänger för användarberättelser som mål

Att formulera användarberättelser, user stories, är ett vanligt sätt att fånga användarkrav i agila projekt. Och det är vanligt att poängbedöma användarberättelser efter hur mycket arbete man tror krävs för att implementera dem. Men poängen i sig har inget värde, de är ett verktyg för att medlemmarna i ett team ska få en gemensam bild av hur komplext ett projekt är och vilka förmågor ett team besitter. Ett teams trepoängsberättelse kan vara ett annat teams fempoängsberättelse. Faran med att bedöma arbetet efter antal ”genomförda” poäng är att man missar det verkliga måttet för framgång: Att leverera fungerande och användbar mjukvara. Kom överens med produktägare och användare om hur man ska mäta det.

3. Jämför hastighet för team eller för individer

Många utvecklare är besatta av mätetal, men det är fel att använda avklarade användarberättelsepoäng per iteration (sprint) för att jämföra team. Och det är lika fel att använda samma mätetal för att jämföra teammedlemmar. Det är ett hastighetsmått som bara är till för att hantera uppskattningar. Det är meningslöst att jämföra team med det måttet eftersom det betyder olika saker för olika team, samma sak gäller för olika individer. Det är slöseri med tid och till och med kontraproduktivt att göra det.

4. Formulerar arbetsuppgifter i stället för berättelser

Om de berättelser som formuleras egentligen är förtäckta arbetsuppgifter så kommer ett utvecklingsprojekt att bli uppgiftsorienterat (att göra saker), i stället för att vara fokuserat på att leverera värde. Det gäller att hitta rätt balans. En berättelse ska inte vara mer omfångsrik än att den kan implementeras under en iteration i ett projekt, vilket gör att det blir meningslöst att dela in den i flera arbetsuppgifter. Det är också meningslöst med en berättelse som bara är delvis färdig. Dela upp den i delberättelser om den inte kan slutföras under en iteration. Mer om det i nästa punkt.

Läs också: Unga mentorer ska lära företagen att locka yngre kompetens

5. Delar in berättelser i arbetsuppgifter

Det är fel att dela in en stor berättelse i flera mindre enbart för att de ska kunna slutföras under en iteration vardera. Resultatet blir uppgiftsorienterade berättelser. Behåll i så fall den stora, och naturliga, berättelsen och hantera den under flera iterationer. Hantera den från början till slut i varje iteration. Börja med den ”tunnaste” fungerande implementationen och fyll på med funktionalitet i nästkommande iterationer. Det kan bli så att naturliga underberättelser kan formuleras när man har en minimal fungerande implementation klar. På det sättet fokuserar man på att tillföra värde med mjukvaran, i stället för att lösa uppgifter.

6. Misstar Scrum för agilt

Scrum är en teknik för att hantera processer, inte för att utveckla mjukvara. Samma sak med Kanban. Scrum och Kanban utan starka agila principer kommer att medföra en återgång till vattenfallsprojekt. Det här blir extra tydligt i stora organisationer med stora initiala ”backlogs” (samlingar av ogjort arbete). Det blir en inbjudan till vattenfallsdesign i stället för inkrementell förfining och till ”standardiserade” agila arbetssätt.

7. Har stor backlog

Om du vill se till att det tar lång tid att gå från att kläcka en idé till att sätta den i produktion ska du se till att ha stora köer med arbetsuppgifter som ska utföras. Tyvärr planerar, godkänner och genomför många företag fortfarande stora utvecklingsprojekt, vilket leder till stora backloggar från början av projekt, vilket är en garanti för att det tar lång tid att lägga till funktionalitet i slutet av projekt. Projekt finns egentligen inte, de är bara mentala modeller. Vi har uppfunnit projekt för att kunna prata om oklara arbetsströmmar som om de vore tydliga enheter av tid och arbete. Det finns inga projekt, det finns bara produkter. Tricket är att förminska. Organisera projekt runt initiala volymer av funktioner som ger mätbart värde och följ upp med vågor av små, mätbara förbättringar.

Sida 1 / 2

Innehållsförteckning