2010-10-20: Per-Magnus Skoogh
LÖSNINGEN PÅ VÄRLDENS PROBLEM Det gick inte så bra och då skall man tänka mer före. Vi tänkte inte riktigt bra innan och då måste vi tänka än bättre före nästa gång. Det låter vettigt eller hur?
Detta påstod till och med forskare från KTH i CIO Sweden för ett tag sedan. Mer och bättre kravspecar är lösningen på all världens problem.
För att citera min kära kollega Mats Janemalm ur hans artikel i CIO Sweden (56 | CIO Sweden 5, oktober 2010, www.cio.se).
De verkar inte ha märkt att framstående förståsigpåare som Peter Drucker och Stephen Covey pratat om att kunskapsarbetarens tid är kommen. Det verkar inte som att de märkt att det vuxit fram metoder och ramverk som kallas Agile och Lean. De verkar inte ha uppmärksammat att dessa synsätt bevisligen leder till goda resultat, och att det inte beror på att man fokuserar mer på att skriva kravspecifikationer.
Och visst är det konstigt? Det predikas fortfarande mer kontroll och mer dokumentation på många håll. Men så är det, när två paradigm krockar med varandra. En som handlar om att tänka efter före och noggrant specificera vad jag vill ha. En annan som handlar om att tänka lite, men inte så mycket, innan jag sätter igång, för att sedan tänka desto mer under tiden som jag kör.
Men vem har rätt?
Agil och cool som jag är har kravspecifikationsprofeterna naturligtvis helt och hållet fel. Usch och fy så hemskt fel man kan ha.
Men samtidigt – ligger det något i allt detta vurmande för tydligare och mer detaljerade krav, tro?
I ett lättrörligt och dynamiskt (agilt) perspektiv måste vi klargöra att krav och detaljering av krav faktiskt är viktigt. Mycket ny erfarenhet och forskning inom agile tyder på detta, vilket kräver en hög disciplin.
Den stora skillnaden ligger egentligen inte i om vi skall specificera mer eller inte utan NÄR det sker. Kravspecifikationsprofeterna kräver krav och detaljer innan vi sätter igång. Agile, å sin sida, kräver egentligen samma sak, fast under tiden istället för innan.
Jag var just uppe hos ett försäkringsbolag som påbörjat resan mot att bli mer agilt i förra veckan, och där visade vi upp teamrummet för intresserade från andra delar av organisationen. Där stod jag tillsammans med Scrum Mastern framför en agil kanban och förklarade för åskådarna vad den var bra för.
Den såg ut så här:
En agil kanban är ett sätt att bryta ner kunskapsarbetarens arbete i en leveransperiod (sprint om ungefär två veckor) i mindre delar. Varje dag ställer sig teamet framför sin kanban och diskuterar vad som blev klart igår (flyttas till ”done”) och vad som skall göras idag (flyttas till ”doing”).
Och där, slog det mig, var allt som det skulle vara: både tekniken och kravbilden nedbruten i en storlek om 4-timmar på den lägsta nivån. Nya nedbrytningar föddes och dog hela tiden. Snacka om detaljerad kravspecifikation, om man tänker traditionellt.
Så visst, kraven behöver brytas ner och detaljeras, men inte före utan under tiden som vi kör. Det är den stora skillnaden.
Och en sak till: vet du vad som gör Zlatan så himla bra? Liksom Beatles? Att han är född duktig? Någon form av gen som slog in på rätt sätt? Javisst, det ligger lite i det – men den stora skillnaden mellan framgång och avsaknad av framgång börjar faktiskt på D.
Foto: Якушкин Иван, Wikipedia Commons
Zlatan går upp klockan fem på morgonen och gör det han måste göra. Tränar. Beatles spelade sex till åtta timmar om dagen i Berlin i två år. Övning, förbättring, övning och åter förbättring är receptet. Det vill säga,
d-i-s-c-i-p-l-i-n
Disciplin är en av de absoluta hörnstenarna för framgång i de agila teknikerna. Agile är långt mer disciplinerat än något annat arbetssätt eller metod för kunskapsarbetare någonsin varit, och just avsaknad av disciplin är ett av många tecken på ett mindre lyckat användande av agila angreppssätt. Skillnaden är att framgångsrika agila team inte är disciplinerade i förväg utan under tiden de jobbar. Vilket betyder att kraven på disciplin som forskarna på KTH kräver är helt rätt, men de är helt ute och cyklar när det gäller när denna disciplin skall appliceras.
Titta på kanban-tavlan ovan. Nog ser den någorlunda disciplinerad ut? Och inte är det jag som gjort den, utan ett team av duktiga och fokuserade kunskapsarbetare.
Och det är det som är trenden – disciplin och koll på läget är på väg tillbaka, fast på ett roligt, kreativt, spännande och kommunikativt sätt. Det är för det mesta så himla kul och naturligt att arbeta på det här sättet att ingen tänker på att det vi gör i nedbrytning och fokus ofta är ljusår tydligare än hur det var innan, och detta med en detaljeringsgrad som värsta metodfascisten från 1970-talet aldrig skulle klara av.
Per-Magnus Skoogh har många års erfarenhet av att använda och införa agila processer och arbetssätt. Han var bland de allra första i Sverige med att börja använda formellt definierade agila arbetssätt, när han för knappt 15 år sedan började arbeta med DSDM/atern. Sedan dess har Per-Magnus använt olika agila tekniker från Scrum till XP i projekt i Sverige, Tyskland och England. Idag hjälper han och hans kollegor olika kunder med att ta till sig agila tekniker av olika sorter med en fokus på ökad verksamhetsnytta.
blog: www.magile.org/pmblog
twitter: twitter.com/pmskoogh
book: www.agile4managers.com
e-mail: per-magnus@mpeira.se
#1 jarmo Järvenpää |
fredagen den 3 december 2010 kl. 23:23 |
Hej jag håller med dig i det mesta som du skriver, och jag älskar agila metoder.
Men jag tänker svar på fråga du ställde i inledningen . vem som har rätt ? Jag tycker att svaret är enkelt: Den som gör det som är bäst för kunden ! Observera att jag skriver det som är bäst för kunden inte det som kunden efter frågar. Eller ? Jarmo Järvenpää
#2 Paul M |
fredagen den 7 januari 2011 kl. 13:44 |
Nu var det ju Hamburg vi spelade en hel del i, betydligt mer än i Berlin...
/Paul M
#3 Lennart |
torsdagen den 19 maj 2011 kl. 08:54 |
Bra artikel! Disciplin men även ansvarstagande skulle jag vilja lägga till. I många agila tankesätt så är vi baktunga på utvecklingsinsatserna, men hur hänger affärsmässiga prioriteringar samman med varje enskild "lapp"? Varje funktion som enskilt ska prioriteras borde väl medföra en nytta för verksamheten? Hinner vi vara så agila med krav och affärsnytta samtidigt som vi utvecklar? Om IT utvecklare inte är på det klara med vad verksamheten vill uppnå så spelar det kanske mindre roll om vi styr utvecklingen med kanban, scrum eller annan agil metod?
Ser du någon kommentar som du tycker är kränkande eller olaglig? Då kan du anmäla den här >>
Skriv en kommentar...