anders lisdorf bloghoved

Agile curlingbørn og fremtidens hybride virkelighed

Nu har jeg endelig fundet ud af, hvad agil udvikling egentlig betyder: det betyder, at alle dem, som arbejder sammen med agile teams skal være agile og fleksible og smide alt, hvad de har i hænderne, når det agile team pludselig har brug for dem. Det kan være systemadministratoren, som pludselig skal konfigurere en ny server i nattens mulm og mørke fordi det agile team, jo har en release i morgen. Det kan også være informationsarkitekten, som skal reviewe datamodellen ASAP. Eller det kan være sikkerhedsafdelingen, der lige skal godkende autorisationsløsningen i sidste øjeblik inden løsningen deployes.

Agile teams er faktisk ofte lidt ligesom curlingbørn, meget utilfredse med alt omkring sig, som de synes er gammeldags og kedeligt og dumt, men samtidig afhængig af, at der er nogen, som lapper alle hullerne og slukker ildebrandene bag dem. Ligesom curlingbørn er de også dejlige, inspirerende og kommer med nye løsninger på gamle problemer så vanetænkningen udfordres.

Agil organisering

Agile teams fungerer rigtigt godt når de har kontrol over alt selv. Ingen tvivl om, at de er uovertrufne der. Men det er ret få steder ude i den virkelige verden, når man når videre fra stadiet garage firma, hvor man har fuld kontrol over alt, og ikke er afhængig af andre.

Hvis man kigger på de agile metoder, som man kan finde dem beskrevne i f.eks. Kanban, Extreme Programming, Scrum eller Agile manifesto, så er det niveau de opererer på: teamet. Der er intet over intet under. The agile manifesto nævner intet om, hvordan man vil samarbejde med andre, Kanban overlader det til eksisterende eller tilfældige processer at finde ud af, hvordan man skal modtage og aflevere arbejde. Scrum og Extreme programming antager bare at en backlog af ting, man kan lave eksisterer eller bliver bragt til at eksistere. De siger intet om, hvordan man tackler user stories, som har afhængigheder til user stories i andre teams.

Det handler om at finde en kadence, hvor man kan spytte noget funktionelt software ud, og en eller anden som kan fodre udviklerne med opgaver. Det er det. Alt kredser om hastighed, som disse metoder har gjort store fremskridt i at forbedre. Som jeg tidligere har skrevet antages det implicit at struktur blot opstår af sig selv, ikke at det skal planlægges eller aftales med andre. Det kan teoretisk set godt være tilfældet, men det er under nogle omstændigheder, som ikke normalt er tilstede.

Traditionelt modstiller man Agil med plan drevet udvikling, som ofte forbindes med vandfaldsmodellen. Formålet er at vise at agil udvikling er meget hurtigere og, ja, mere agil i forhold til ændringer. Hvilket er rigtigt, men der er også andre kvaliteter ved løsninger som er vigtige at tænke på:fremtidig vedligeholdelse, arkitektur og lignende, som man ikke normalt har kigget på fordi det agile paradigme har haft held til at holde fokus på lige hastighed.

Plan drevet udvikling er ganske rigtigt langsommere og fejler ofte monumentalt, men det kan lige så godt være fordi det typisk er større projekter, som af natur rummer mere kompleksitet og koordination. Eller at det er større, ældre og mere komplekse organisationer som bruger dem. Der er en del forskning som har peget på, at lige netop projektstørrelse uden sammenligning er den vigtigste indikator for succes. Der er desværre nogle projekter, som er så store, at man ikke bare kan skære det ud i småstykker og fodre dem til agile teams og så regne med at alle komponenterne spiller sammen bagefter. Nogle gange er der noget koordination imellem teams og andre interessenter, som ikke blot løses ved daglige standup møder.

Hybrider er fremtiden

Der er dog intet i verden, bortset fra dogmerne og parolerne, som forhindrer at de to udviklingsparadigmer kan eksistere sammen. Faktisk er agil udvikling allerede blandet grundigt sammen med plandrevne metoder ude i virkeligheden. Et nyt studie, som lige er publiceret af Actuation Consulting om “The Study of Product Team Performance 2015” viser, at den klart mest udbredte metode er en hybrid tilgang, som 43% af alle firmaer bruger. Agil og Kanban tegner sig for små 30% samlet og vandfald for ca. 14%. Vejen frem er derfor at finde en måde at få integreret alle de gode sider af agil udvikling med en form for overordnet planstyring.

Det er derfor interessant, at se at der er en række nyere bud på udviklingsmetoder, der prøver at integrere agil og plandrevet udvikling. Et eksempel fra det plandrevne udviklingsparadigme er PRINCE2 Agile, som har suppleret et plandrevet rammeværk med agile elementer http://www.apmg-international.com/en/qualifications/PRINCE2Agile™/PRINCE2Agile.aspx . Der er dog også eksempler på at agile udviklingsmetoder bliver suppleret med plandrevne elementer for at nå en vis grad af enterprise styring. En af dem som er i stor fremgang i USA, er Dean Leffingwell’s Scaled Agile Framework eller SAFe . Det har dog ikke rigtigt slået igennem i Danmark endnu, selvom der begynder at komme kurser i det.

Leffingwell er helt igennem en agil fyr og bogen hvor ideerne præsenteres i hedder spøjst nok “Agile Software Requirements", men han har puttet nogle ekstra styringslag ovenpå det agile, som gør en kæmpe forskel. På team niveauet arbejdes der helt almindeligt agilt, men over dette findes et program niveau. Dette samler en række teams og arbejder agilt med disse. på program niveauet arbejder man ikke med user stories, men istedet med features. Det er her man normalt ville have en program manager eller en product manager, som leder og prioriterer, hvad der skal udvikles. Han skubber en feature ned til et team, som bryder det ned i user stories. Oven over programniveauet er et portefølje niveau. Her planlægges på epic niveau. Der findes business epics og architecture epics. Sådanne epics varer typisk længere end et sprint. En epic kan skubbes ned til team niveauet, hvor det brydes op i stories. Leffingwell anbefaler at man holder op med at lave budgetter men hele tiden vurderer hvad der skal laves løbende, men det anbefales dog at man beslutter sig for nogle investment themes, som man så kan sætte en procent andel på.

At der er interesse for at integrere ovenliggende styringslag kan også ses på udviklingen i agile tools. Jira og Rally arbejder f.eks. på at integrere disse overliggende styringslag i portefølje moduler.

Det vil derfor være nødvendigt at finde den rigtige måde at arbejde på i hver situation. Det er meget tænkeligt, at det kan være forskelligt fra industri til industri. Jeg har ikke endnu set en magic bullet, som præcist rammer alle behov. Som vi så ovenfor så arbejder de agile bare videre indenfor deres paradigme og de plandrevne indenfor deres, men man kan håbe på at der opstår en udviklingsmetode, som opfylder begge behov, den agile effektive udvikling og firmaets behov for at planlægge og styre.

Personligt tror jeg, det giver mere mening at prøve at bryde alle dogmerne op og finde de elementer, som virkelig giver værdi. Det handler om at identificere agile byggeblokke, som kan bruges i sammenhæng med en plandrevet rammeværk, hvis firmaet har en smule historie, størrelse eller kompleksitet.

Referencer

The agile manifesto

David J. Anderson: “Successful Evolutionary Change for Your Technology Business"

Dean Leffingwell: “Agile Software Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise

Kenneth S. Rubin: “Essential Scrum: A Practical Guide to the Most Popular Agile Process

Kommentarer (1)
Martin Eskildsen

Jeg tror at den Agile verden (selvforskyldt og uforskyldt) har fået malet et forkert billede af sig selv:

"Hvis bare du kører agilt kan du tilpasse dig alt!"
"Hvis bare du kører agilt behøver du ikke planlægge så meget!"

Og flere andre i samme boldgade. Det lyder besnærende; mere kage, mindre rugbrød. Men det er bare ikke rigtigt for mange områder af udvikling:

  • Hvor projektet er stort og simpelthen kræver masser af hænder over lang tid
  • Hvor projektet er "stærkt koblet" til omverdenen, for nu at bruge et software koncept
  • Hvor du ikke har meget tid, eller dine ressourcer er fuldt udnyttet

Man har en tendens til at overse at produkterne skal fungere i en sammenhæng, og at den sammenhæng ofte er relativt kompleks. Så derfor er man nødt til at lave aftaler med andre: Om leveringstidspunkter, om features og prioritering deraf, om hvornår hvilke ressourcer er tilgængelige (og et team kan være én sådan ressource) og så videre. Derigennem taber man fleksibilitet; man kobles tættere. Og det kan godt være at det er anti-agilt, men det er ikke desto mindre en typisk rammebetingelse.

Så "naturligvis" slipper man ikke for at planlægge, og undertiden planlægge ret grundigt. Man skal blot søge kun at planlægge det nødvendigste og så lade resten være situationsbestemt; på den måde kan teamet se sig i en større sammenhæng og kende sin rolle deri, men samtidig have stor fleksibilitet på detaljerne, fx: "Vi har, som virksomhed, lovet at levere features A, B, C til 1. december med en prototype på feature B i midt november. Men derudover har vi frit slag."

Så for mig kører man bedst agilt ved at være opmærksom på et konkret projekts behov for systematik. Det varierer fra gang til gang, og det er vel også ganske agilt.

Log ind eller Opret konto for at kommentere