Ful-Agile

Ganska många organisationer säger sig idag ha anammat lättrörliga arbetssätt. I en internationell undersökning från 2006 av 722 organisationer, stora som små, svarade 84% att de “arbetade lättrörligt”. Men kan man tro på den siffran? Knappast.

Inte för att de skulle ljuga, de har säkert gjort minst ett officiellt lättrörligt projekt, utan för att detta knappast innebär att deras personal har agila värderingar och attityder. Och det är det som Agile till syvende och sist handlar om. Det är dessa redskap som hjälper oss i alla dagliga beslut när arbetssätt och praxis inte räcker till. Annars blir det mest “Ful-Agile”.

Låt mig ge några exempel: Du vet att någon inte förstått Agile när utvecklaren utbrister: “Jag kan inte jobba med det här, det är för dåligt specat”. För det första, vi “specar” inte i lättrörliga metoder, vi föredrar kommunikation ansikte mot ansikte. För det andra, med denna mening frånsäger sig utvecklaren allt eget ansvar och initiativ. Det här luktar lite babyprogrammerare som förväntar sig bli skedmatade med specar för att sedan rapa upp en illaluktande kodsörja (om liknelsen ursäktas).

Du vet att någon inte i grunden förstått lättrörligt när de gör något som alla ingenjörsmässigt inser är dumt och säger “Men kunden har ju sagt det”. Detta är också en abdikering från allt ansvar. Var är yrkesstoltheten? Ditt ansvar som expert är att berätta för kunden om risker och konsekvenser med olika beslut, bistå kunden tekniskt, kanske till och med vägra om det är alldeles på tok.

Du vet att folk inte har snappat vad det handlar om när man ser sig som ägare för olika delar av ett system (systemet är allas ansvar), när man inte avlastar varann och hjälper varann (vi är ett team med samma mål) eller när man ser iterationens krav som godispåsar som man bara kan plocka det gottaste av (vi åtar oss att leverera inkrement med korta, regelbundna intervaller).

Ovanstående exempel är inte Agile – det är Ful-Agile och måste som sådan bekämpas. Hur är det på ditt företag, kör ni Agile eller Ful-Agile?

Fotnot: Den här texten finns också publicerad på Terrier Softwares webbplats.

3 thoughts on “Ful-Agile

  1. Pingback: Datateknikelit :: Vad kännetecknar agile? :: March :: 2007

  2. Hoppsan! Jag blev lite provocerad! Kul, det händer inte ofta när man läser de vanligtvis bleka inläggen i folks bloggar.

    Jag är som många utsatt för SCRUM, och det funkar bra! Problemet är just att specning (och då menar jag inte hyllmeter med dokument utan ett kort snärtigt dokument som beskriver implementation av en viss backlog item) inte addresseras i SCRUM.

    Denna lilla spec kan fungera som ett sätt att snabbt överföra kunskap och minskar risken radikalt att man missar nån vital del i systemet som påverkas av förändringen.

    Vi som jobbar med komplexa system med många integrationer till externa system som är i drift 24/7 med tusentals samtidiga användare vill gärna ha torrt på fötterna när vi sjösätter en ny feature. En analys (spec om än minimal) av nya features är tillsammans med enhetstester och strukturerade manuella regressiontester det enda sättet att garantera att systemet inte står på huvet efter release.

    Läs om SCRUM i min blog: http://hellrefaraherde.blogspot.com/2007/11/15-minuter-daglig-masspsykos.html

  3. Hej mrdev22,

    Tack för kommentaren! Kul att höra att du tar det så positivt att bli provocerad.🙂

    Visst är mitt inlägg i viss mån avsett att provocera. Vad jag egentligen försöker komma åt är folk som använder agile som en accessoar, ett modeord, och sen undrar vad som gick snett. “Var det wordmallarna som inte var tillräckligt bra måhända? Ja, så var det nog.”

    Om ett “snärtigt” dokument, i din uppenbarligen mycket komplexa miljö, hjälper er att formulera och komma ihåg era tankar är väl det bra. Det var inte främst sådana som jag avsåg med “spec” i mitt inlägg. Här siktade jag egentligen in mig på var folk som ser för snävt på sin roll i teamet. Är det att göra “mina uppgifter” eller är det att uppnå projektmålen på alla möjliga sätt? Allt för många kör med “inte mitt bord”-mentalitet, tycker jag.

    En tanke: Behovet att specificera //kan// också vara en indikation på att ni arbetar med för stora “batchar”. Ju mindre delar man har desto snabbare genomströmning får ni (jmf köteori).

Comments are closed.