Scrum tillsammans med existerande metoder

Ibland känner jag mig lite kluven i min syn på hur man ska anamma nya metoder. En del av mig tycker att man ska behålla det som fungerar och inte ändra för mycket men en annan sida av mig tycker att man ska ta till sig allt i det nya. När man sedan ser vad som inte fungerar i den aktuella organisationen ska man så klart göra anpassningar. Det är ju det agile handlar om!  Om vi tar Scrum som exempel hör jag många säga att ”Vi vill införa Scrum men vi kan inte placera våra testare i teamet.” Hur ska man då förhålla sig till det? Hur ska man hantera att inte alla organisationer kan börja med ett vitt blad?

Anledningen till att man vill införa en ny systemutvecklingsmetod är oftast att något i det existerande arbetssättet inte fungerar. Jag säger oftast för det pågår ju onekligen en rätt stor hype runt Scrum och det finns nog en hel del organisationer som bara hänger med i utvecklingen. Min grundinställning är att man ska försöka se vad som fungerar och vad som inte fungerar för att sedan börja byta ut det som ställer till problem. Om vi tar fallet jag beskrev ovan med en organisation med en väl fungerande testavdelning där man inte vill bryta den upp och placera testarna i teamen, då tycker jag att man ska behålla den och börja med att organisera om utvecklingsteamen. Börja med att få in ett mer testdrivet sätt att utveckla och involvera testavdelningen tidigare i processen.  Se inte varje sprints leverans som en leverans till test utan ha fortfarande ambitionen att det som levereras ska vara ”potentiellt levererbart inkrement av produkten”.

Min erfarenhet är att det är organisationer med t ex en stark Rational Unified Process (RUP)-tradition som har starka och styrande testavdelningar. Man börjar med att se hur mycket testtid som behövs och räknar sedan bakåt för att komma fram till hur mycket utvecklingstid som blir kvar. Utvecklarna levererar sedan något som är halvfärdigt och förväntar sig att det testas och återkommer som buggrapporter. Det här är ett väldigt ineffektivt sätt att arbeta och det blir mycket bättre med mer fokus på test tidigare i processen. 

Även om organisationen i övrigt jobbar enligt RUP så är min erfarenhet att man kan införa Scrum som arbetssätt men det kommer att kräva vissa förändringar i det existerande arbetssättet. Att bara byta ut utvecklingsfasen tillför inte så mycket utan iterationslängden måste kortas ner och i alla fall få med analys och design-faserna i Scrum-tänket. Iterationerna i RUP tenderar att bli relativt långa jämfört med t ex Scrum och jag tror att det har att göra med att det är så mycket slöseri inbyggt i processen. Slöseri i form av dokumentation som bara skapas för att göra en överlämning från en fas till en annan.

Jag tycker att det har fungerat bra att köra Scrum i organisationer som normalt använder en annan metod. Under 2008 satt jag på uppdrag hos en kund som använde ITIL för att hantera alla sina projekt, dvs de använde ITIL för att kordinera mellan projekten och säkerställa att de levde upp till olika förväntningar. Där fanns en definition för när en förändring i ett system skulle klassas som ett projekt och de hade inte någon uttalad metod för hur utvecklingsprojekt skulle drivas. Organisationen var väldigt agil i sitt arbetssätt med en mycket aktiv produktägare så att inför Scrum där gick väldigt bra.

Vi hade så klart krav på oss från ITIL att leverera det som förväntades i from av olika dokument till beslutsmöten och det löste vi genom att placera det på vår sprint backlog som en uppgift. Han som var ITIL Release Manager fick jobba rätt hårt med andra projekt för att få dem att leverera de förväntade dokumenten medan vi levererade varje gång. Att leverera dessa dokument var en punkt som vi hade prioriterat och estimerat och levererade precis som allt annat.

Jag är medveten om att det inte alltid är lika lätt som vi hade det där utan att det ofta finns mycket politik och inbyggda rutiner som man måste hantera när man inför en ny utvecklingsmetod. Min grundinställning är nog ändå att man ska behålla det som fungerar och börja med att göra förändringar där man har problem. Ambitionen bör dock vara att anamma så mycket som möjligt för att kunna dra nytta av styrkan i Scrum.

Mvh Björn Eriksen
Björn jobbar till vardags på Connecta som systemarkitekt.

Taggar:

• Agile
• Björn Eriksen