I en virksomhed har nogen læst en bog om agil udvikling. Forretningen og udviklingsafdelingen er enige om, at det nok er en god idé at prøve noget nyt. Den gamle metode med få årlige afleveringer af features har ikke rigtig fungeret, og det ender med at man alligevel laver ukontrollerede leverancer hele tiden.
Især ledelsen, der har mistet tilliden til at udviklingsafdelingen kan levere, tænker at det er en god idé at udviklerne skal aflevere hele tiden. Så kan det være, at de lærer det. Her følger en historie fra det virkelige liv, hvor udviklingsafdelingens hjælpsomhed overfor forretningen er en del af problemet.
Nu bliver processen agil. Hver uge mødet udvalgte repræsentanter fra forretningen og udviklingen for at planlægge næste uges arbejde. Mødet har ingen agenda og der tages ikke et formelt referat. Forretningen har featureønsker med, men ingen specifikationer.
På et tirsdagsmøde siger en fra forretningen, at han gerne vil have lavet noget om ved nyhedsbrevet. Han beskriver, hvad han gerne vil have lavet, og udviklingschefen forklarer, at det er ret ligetil og kun tager en time.
Efter mødet sætter chefen en anden til at løse opgaven, og ham, der skal have opgaven løst, er heller ikke med til mødet. Nu har vi to mand, der skal løse en opgave, der er besluttet på et møde hvor ingen af dem deltog, og der findes ikke et referat.
Ham, der skal have opgaven løst, har ikke fået adgang til udvikler-teamet i måneder. Nu, hvor en rigtig udvikler kommer ind af døren, er der er lang liste over, hvad der skal laves.
Det handler alt sammen om nyhedsbrevet og begge er i god tro. Udvikleren er sikker på, at ham i forretningen ved, hvad opgaven går ud på. Ham i forretningen har fået at vide, at udvikleren skal hjælpe med nyhedsbrevet.
De diskuterer og estimerer opgaven på et fælles møde, der tager to timer. Nu er udvikleren klar til at løse opgaven - men han har lige nogle driftsopgaver, der skal løses først. Det tager onsdag og torsdag, men så er bordet ryddet.
Fredag morgen er udvikleren klar til at gå i gang med nyhedsbrevet. Uheldigvis arbejder man ikke med test, så det viser sig at den gamle kode, der skal skrives om, ikke har det ret godt. Allerede i løbet af fredagen er det klart, at mandagen også må tages til hjælp.
Det ser ud som om det hele lige kan blive klar mandag eftermiddag. Men det kan det ikke. Mandag er der brugt 16 timer til at kode plus de 4 timer til at mødes. Koden virker næsten, men ikke helt. Udvikleren er en samvittighedsfuld person, og der er også blevet kodet lidt i weekenden. At nå det hele var bare ikke muligt. "Forretningen må lære at begrænse sig", tænker han.
Tirsdag morgen forklarer udvikleren sin chef, hvad forretningen har bestilt, hvad der er lavet og hvor tæt de nye features er på at være færdige. Så er det tid til tirsdagsmødet.
Som sædvanlig er listen over, hvad der er sat i gang, temmelig meget længere end listen over, hvad der er blevet færdigt. Forretningen spørger naturligvis til den lille feature, de bestilte. "Det går rigtig fint", siger udviklingschefen. "Vi mangler kun omkring fire timer".
Find selv fem fejl. Måske har du prøvet noget lignende? Hvad skal forretningen lave om, og hvor kan udviklerne blive dygtigere?
...så kræver velfungerende udvikling at vejen mellem dem som stiller opgaven og dem som udvikler er kortest mulig, mellemmænd komplicerer det hele, til gengæld er det vigtigt at der er en med til mødet som kan sikre at ham som stiller opgaven og ham som udfører den kan forstå hinanden (hvilket ikke altid er lige til at gennemskue).
Det lyder som om de skal få styr på deres product owner setup så ønskerne bliver specificeret med ordentlige done-kriterier. Måske de skulle genlæse bogen eller bestille ekstern coaching for at komme on track
Jeg kunne egentlig godt tænke mig at høre lidt nærmere om de "driftsopgaver" der lige skulle løses først? Jeg kan godt lide DevOps princippet - men det skal være gennemtænkt, noget kunne tyde på det ikke var tilfældet her.
Det væsentligste problem her, er at man har tilladt at have andre end de(n) leveringsansvarlige til at udtale sig om hvor lang tid, det tager at blive færdige. Historien her handler tilsyneladende om en virksomhed hvor man tror at "agil" == "kortere leveringsfrister".
Lasse, jeg lover at intet var gennemtænkt her, men det er faktisk blevet en god historie. Det er idag en meget velfungerende udviklingsafdeling.
Den vigtigste ændring har været at bringe forretningen og udviklingsafdelingen sammen. De sidder fysisk i samme del af bygningen nu. Det er nyt.
Der er indført rigtig agil udvikling, som både er godt planlagt - men der anvendes nu også tidsregistrering og der er en opfølgning på leveret tid i forhold til estimat. Der er kommet en product owner og der er nu kriterier for Done.
At "intet er umuligt for den, der ikke skal løse opgaven selv" er lige i øjet her. Det var tidligere for let for forretningen af aflevere en dårligt beskrevet opgave og slippe afsted med det. De hjælpsomme udviklere ville altid gøre hvad de kunne for at løse opgaven uanset hvad. Ordet "nej" fandtes ikke. Det er nok det vigtigste ord for en udvikler, når forretningen ikke leverer det de bør - selvfølgelig med en forklaring om hvad det er, der mangler.
Min erfaring er at, det som udvikling laver, kommer de også selv til at vedligeholde og holde i luften til en vis grad.
Det er sjældent at jeg har oplevet at udvikling har lavet noget software som bliver sendt i drift, og som en driftsafdeling kan holde i luften uden hjælp fra udvikling.
Så det er sikkert det der dokumenation og test der har haltet :-)
Selvfølgelig skal der være gode specifikationer tilstede, det ændre agil udvikling ikke på. Hvis ikke specifikationen findes, skal den produceres og bliver til en agil opgave for teamet at producere, jeg tror ikke det har noget med udviklernes kvalifikationer at gøre, men nemlig manglende spcifikation og god styring fra product owner -han skal også være sin opgave voksen jo.
Ingen tvivl om at der var meget andet galt - men lige den med "driftsopgaver" var en trigger for mig, fordi jeg har siddet i den position mange gange. (Hvilket på den ene side er ganske spændende, på den anden side kan være temmeligt farligt, fordi man nemt falder mellem to stole.) Min pointe er at samarbejdet mellem drift og udvikling også er ret væsentligt for, hvordan et system kan driftes og ændres. Og jeg har da oplevet mere eller mindre hårrejsende ting på den front...
Jeg synes, det ser ud som om, at nogle af kommentarerne kommer til at sætte lighedstegn mellem agil udvikling og scrum
Det største problem for mange agile projekter - scrum eller ej - er faktisk at ledelsen ikke er særligt godt uddannet. Det giver en række misforståelser.
Nogle steder tror ledelsen at agil udvikling betyder, at det er uden omkostninger at skifte retning. Andre steder er det lig med hurtigere leverancer, for "nu bliver det hele mere effektivt".
Når det sker, har udviklingsafdelingen en opgave med at sætte hælene i, og her er det vigtigt at have styr på egne projekter, så man kan dokumentere hvor lang tid ting tager og hvorfor. Ellers bliver man ikke lyttet til.
Naar nu det er defacto standard at rekrutere IT chefer fra finance, saa kan det vel ikke undre at de ikke har den fornoedne viden om udvilking, og efterfoelgende maa gennem et utroligt kostbart indlaerings forloeb som beskrevet. Selvom afdelingen nu er en success saa har det taget alt for lang tid at naa dertil og vaeret alt for dyrt for forretningen. Normalt ville vi ogsaa have mistet et par dygtige udvilkere paa den konto.
Altså lige ud over at de har læst en bog om det. Scenariet her lyde for mig ikke kun som et forfejlet forsøg på at arbejde agilt, men et mere grundlæggende problem i organisationen. Et problem der desværre findes mange steder ligegyldigt om man arbejder Agilt, Virilt, Sterilt eller hvad man nu vælger at kalde det.
Enig i at mange indfører agil udvikling uden at ane hvad det er de går ind til og uden at få den rigtige hjælp. Man blive jo ikke maskin ingeniør bare ved at købe en drejebænk. Er også enig i kommentaren om at mange sætter lighedstegn mellem agil og Scrum, hvilket både bekræfter drejebænks analogien og er direkte farlig for om agil udviklng i en organisation bliver en success eller ej. Agil er en mentalt tilstand og ikke et værktøj.
Det er skam ikke spor agilt, Henrik. Det bliver vi hurtigt enige om. Det eneste der var agilt her, var selvopfattelsen.
I det konkrete projekt var it-chefen i øvrigt ikke en økonomimand, men det er mange steder tilfældet. Det er både bekymrende, fordi it-chefen så mangler et fagligt ståsted - men når vi i it-branchen kigger indad, kunne vi måske også ønske os at flere it-specialister lærte mere om ledelse.
På den måde ville det være lettere at få it-specialisterne ind på ledelsesniveau.
Der rammer du et interessant dilemma. Et af dem er at der sker så meget på IT området at de IT-specialister der havner på ledelsesniveau ikke kan følge med I hvad der sker af nye tiltag. Det betyder at de efter 2-3 år allerede har svært ved at følge med og derfor risikerer at træffe beslutninger på et forkert grundlag. Jeg har arbejdet under IT-chefer der mente at "de vidste alt om programmering" selvom det var 15 år siden de sidst havde skrevet et program.
Jeg har også set at når en IT-specialist tager leder uddannelser og kommer op i graderne i organisationen, stadig bliver betragtet som udvikler og ikke rigtigt bliver taget alvorligt som leder/chef.
Måske er der behov for en helt ny rolle?
Interessant tanke. Det kan faktisk godt være. Jeg har ikke lige et svar.
Min erfaring er at det er optimalt når udviklere, der havner i lederstillinger, forstår at omstille sig til at være ledere og dermed tager deres erfaring med sig. Det er godt for ledelsen, når der eksisterer en erfaringsmæssig baggrund for at vide hvor lang tid ting tager og hvordan man griber et projekt an.
De chefer, der engang var udviklere, og som mener de (stadig) er eksperter i de enkelte arbejdsopgaver (som de har forladt) er ofte rigtig dårlige til at bedømme situationen.
De kan nu alligevel være et mindre onde end økonomerne, der tænker på udviklerne som bønder i et skakspil. "Vi mangler to ressourcer herovre. Har vi ikke nogle andre udviklere, vi kan sætte på den opgave?" Det er ikke altid 2=2, og det er ikke altid økonomerne vil høre forklaringen (suk).
