1. När dina agila införanden
slår tillbaka
Måns Sandström, Adaptiv
et
e m
s t
S y
2. Executive summary
• Symptom och problem inte alltid på
samma plats
• Förändring kräver förståelse för
bakomliggande drivkrafter
• Förändringar kan behöva
kombineras för att ge önskad effekt
18. Fler fel i sluttesterna
Teamet levererade mindre än utlovat
Defekt!
Längre tid för sluttest
Mer halvfärdigt arbete
Testarna upplevde mindre arbetsglädje
19. O
Ledtider Testtider Kvalitet
O
O
Samtidigt arbete Testares tillgänglighet
O
“Utmanande plan”
Resursutnyttjande
Projektmål
Kostnadsfokus
Budgetmål
20. O
Ledtider Testtider Kvalitet
O
O
Samtidigt arbete Testares tillgänglighet
O
O
WIP-limit
“Utmanande plan”
Resursutnyttjande
Projektmål
Kostnadsfokus
Budgetmål
Inbjuden av företag för att lösa ett agilt projekts problem “i testfasen”\nDe hade “problem i test” som pågått så länge att det börjat bli en storpolitisk fråga.\n\n
De hade “problem i test” som pågått så länge att det börjat bli en storpolitisk fråga.\nNu ville man visa handlingskraft och satsa på att lösa problemet, gärna med automatisering.\n\n
Från beställarens sida hade man attityden att det var möjligt att köpa sig framgång.\n“Säg bara hur många IT-konsulter ni behöver.”\nIT-avdelningen var dock lite mer avvaktande vad gäller att skala upp antalet personer. Kunde man hantera det?\n
Problem manifesterar sig inte alltid där det bör lösas.\nBörjade med att se över hela projektets arbetsupplägg\nInförde åtgärder som “löste problemen”\nSåg hur problemen återuppstod efter hand\n
Otestat till sluttester\nKravutredningar, utvecklingsansträngningar som blev halvfärdiga.\nMot slutet av iterationerna, d.v.s. under test, fick man panik men man hade redan påbörjat så mycket att manövreringsutrymmet var borta. Det blev till att försöka förlänga iterationer så gott det gick. \n
WIP-limit infördes, mest för att göra dem uppmärksamma på hur ofta de påbörjade något nytt istället för att verkligen slutföra.\n
Vi uppmuntrade parprogrammering.\nVarje utvecklarpar fick tillgång till en dedikerad testmiljö.\nPå så vis visste de att ingen skulle störa deras tester. \n
Allt som skulle utvecklas (varje user story) var tvungen att ha en verksamhetsbeställare.\n
Projektledare gick med på att släppa lite på produktivitetskraven med en uppmuntran till utvecklarna att ägna mer tid åt specificerande testning a’la ATDD.\nVill ni veta mer om ATDD så rekommenderar jag varmt Joakim Holms tal senare idag.\n
Vi tog bort ap-testningen från den långa testfasen och fokuserade det manuella testarbetet på utforskande testning: S.k. Session Based Test Management.\n
och dra på trissor\n
Vi fick effekt. För första gången (på 5 år) levererade teamet över sitt åtagande.\nSluttesterna gick från 6 veckors stresskaos till 3 veckor med relativt lugn.\n
Här kunde jag ha slutat:\nLyckat införande, duktig konsult\n...men jag stannade för länge\n...hann se att förändringarna var tillfälliga\n
lyckad förändring fick dem att törsta efter mer.\nFlyttades till andra problemområden\nsåg förändringar erodera och återgå till det gamla vanliga\n\n
Måste jag vara närvarande? Näe, det har ju inte med det att göra.\nSå vad hade hänt?\n
Börja med att förstå vilka krafter som påverkar hur vi arbetar...\n
Bestämma sig för hur vi ska förändra förutsättningarna för att få den effekten vi söker.\nNotera alternativen och deras konsekvenser...\nP.g.a. hur åtgärderna samspelar i orsaksgrafen så kan man behöva se över hur man paketerar sina åtgärder så att man får den effekt man söker.\n
Vi kan ju kalla det rotorsak, men då ska vi ha klart för oss hur ett rotsystem ser ut.\nFem varför visar här en svaghet. Orsaksgrafen är typiskt ganska komplex och om vi letar efter en rotorsak så kan vi bli besvikna när andra drivkrafter träder in och återställer den tidigare balansen. Stameffekt?\n