La oss avgjøre en diskusjon: Er smidig utvikling faktisk en metodikk eller ikke?
Stopp meg hvis du har hørt denne før: «Agilt er ikke en metodikk, det er en måte å jobbe på», eller «Det er en tankegang», eller «Det er en tilnærming».
Man kan hevde at disse ordene bare er synonymer for metodikk, men de mest hardbarkede agile-tilhengerne vil ofte si at det ikke er slik; at tankegangen legger føringer for de mange metodikkene som faller inn under paraplyen (Scrum, Kanban og så videre).
Blir du opphetet nå? Klar til å kaste deg inn i kommentarfeltet med din egen kritiske vurdering, i typisk kommentarkrig-stil? Det har vært utallige argumenter, eller debatter, om dette temaet, både i våre egne kommentarfelt og andre steder på nettet. Kanskje til og med i styrerommene i din egen organisasjon?
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Det er på tide å avgjøre det én gang for alle: Er agilt en metodikk eller ikke? Jeg snakket med sju eksperter på agile arbeidsmetoder og prosjektledelse for å få et endelig svar.
Argumentene for agilt som metodikk
Én ting ser alle ut til å være enige om: Agilt er komplisert. Som Sally Shaughnessy forklarer, «det krever:
- Å prioritere fremgang fremfor perfeksjon (prøv å selge det inn til en kunde)
- Prototyper fremfor planlegging og dokumentasjon (vanskelig for prosjektledere og strateger)
- Historiepoeng og hastighet fremfor dager og kroner (forklar det til den som er ansvarlig for budsjettet)»
Men det er stor uenighet om hvordan det brukes i praksis – er det en metodikk eller en tankegang?
Agilt omtales ofte uformelt som en metodikk. Det finnes mange innlegg, innlegg og historier som snakker varmt om «fordelene med agil metodikk», eller om hvordan «agil metodikk sluker penger og tid», eller om hvor «kraftig og nyttig agil metodikk er». Emneknaggen #agilemethodology er populær.
Her er noen tanker om hvorfor det er så vanlig å omtale agilt som en metodikk.
Forvirring rundt Scrum og agilt
Det er en tendens til å bruke Scrum og agilt om hverandre, selv om de ikke er det samme. Dette skyldes sannsynligvis at Scrum er den mest populære metodikken under den agile paraplyen.
Selv om Scrum kan være agilt, er ikke agilt Scrum:
Innlegg fra compsci
fellesskapet på Reddit
Mislykket implementering
Organisasjoner som forsøker å gjennomføre en agil transformasjon uten gode prosesser for endringsledelse på plass, risikerer å fremstille agilt på en misvisende måte overfor prosjektmedlemmene og andre ansatte som faktisk utfører arbeidet.
Dette gjør teammedlemmene negative til agilt, noe som i deres øyne betyr flere meningsløse møter, mer overvåking og detaljstyring, samt et press om å få ting gjort raskere og med færre ressurser (som vi alle vet at alle bare elsker).
Kommentar
av u/Dogbeast fra diskusjonen Hva er agilt, og hvorfor er det viktig?
i learnprogramming
Å «gjøre» agilt kontra å «være» agil
De som hevder at agilt er en tankegang snarere enn en metodikk, snakker ofte om organisasjonene og teamene sine som at de «er agile», i stedet for at de «gjør agilt».
Team som bare «gjør agilt», har ikke fått tak i hvorfor bak det de gjør. I stedet for å «være agile» og følge måten agilt er beskrevet på i Det agile manifestet, følger de et sett med praksiser (det vil si en metodikk) uten å tenke over hvorfor metodikken er lagt opp på akkurat denne måten.
Når team «gjør agilt», tenker de altså på det som en metodikk – et sett med prosesser og praksiser som skal føre til et bestemt resultat – snarere enn som en tankegang for hvordan man arbeider.
Her er et illustrerende svar på et spørsmål om hvorvidt agilt skal være en gjøremålsliste som brytes ned i mindre arbeidsenheter og fordeles i sprinter, men uten å bruke retrospektiver eller iterasjon.
Kommentar
av u/TheNegroSuave fra diskusjonen Når smidig ikke er smidig
i agile
Argumentet for agilitet som tankesett
Så hvorfor er forkjemperne for smidig arbeidsmetodikk så insisterende på at det ikke er en metodikk, selv om mange ser ut til å omtale det slik som standard?
Liz Lockhart Lance, stabssjef i Performica, hevder at «Agile er ikke én enkelt metodikk. Agile er et tankesett forankret i Agile-manifestet, der fire verdier og tolv prinsipper styrer tenkningen og beslutningstakingen til personer som samarbeider om å utvikle nye løsninger, programvare, produkter osv.»
Hvis du har lest Agile-manifestet, vet du at verdiene og prinsippene Lance viser til, ikke beskriver et spesifikt sett med praksiser eller prosedyrer som må gjennomføres av dem som bruker en smidig arbeidsmåte.
I stedet, som hun uttrykker det: «En agil utøver som praktiserer Agile som et tankesett, vil være åpen for endring og læring, ha mennesker i fokus og sette samarbeid i sentrum.»
Mange av de eksisterende metodikkene som faller inn under den smidige paraplyen, beskriver riktignok spesifikke praksiser og prosesser som støtter dette tankesettet, men Agile-manifestet er igjen ikke spesifikt når det gjelder hvordan organisasjoner og team faktisk skal «praktisere agile».
Sarah Hoban, senior direktør ved programstyringskontoret i Aura, er enig. «Jeg vil beskrive agile mer som et tankesett enn som en metodikk … Du trenger ikke å følge et foreskrevet sett med prosesser for å være agil. »
«Agile er snarere en tilnærming du bruker for å løse problemer. Det handler om å iterere på et problem til du finner løsningen som best oppfyller kundens behov innenfor tidsrammen og budsjettet du har tilgjengelig,» legger hun til.
Som Hoban fremhever, er iterasjon nøkkelen til agile. Både Agile-manifestet og individuelle agile-metodikker oppmuntrer til iterasjon. Når du først arbeider iterativt, produserer MVP-er og ikke er altfor opptatt av at alt skal bli riktig første gang, arbeider du etter et agilt tankesett, uansett om du følger Scrum-prosesser eller Kanban-prosesser.
Eric Risner ACP ®, grunnlegger av Rise Up Leadership, påpeker at agile handler om å la situasjonen eller prosjektet styre hvordan teamet arbeider. «Ordet «agile» er filosofien om å tilnærme seg et prosjekt på den måten som passer best til situasjonen. Det finnes ingen agil metodikk for prosjektledelse som passer alle, ettersom ulike aktiviteter krever ulike tilnærminger.»
Selv om Agile-manifestet kan oppfattes som ganske abstrakt, bringer Risner oss tilbake til å sette agile ut i praksis gjennom mangfoldet av agile-metodikker som faller inn under denne store paraplyen.
Å forene tankesett og praksis
Jesse Fewell, grunnlegger og administrerende direktør i agile-konsulentselskapet Fewell Innovation, hevder at agile må kombinere både det agile tankesettet og praksisen med å «praktisere agile».
Argumentet hans er at når organisasjoner forsøker å gjennomføre en agil transformasjon, må de fokusere like mye på å endre organisasjonskulturen og teamenes tankesett som på de faktiske taktikkene og stegene de skal ta for å lykkes med den agile transformasjonen.
Med hans ord: «Den virkelige magien oppstår når du bevisst kombinerer det beste fra både kulturelle samtaler og strukturelle steg … både det agile tankesettet og den agile mekanikken [går] hånd i hånd.»
Agile er altså ikke en metodikk, men et tankesett. Agile-manifestet gir oss et tankesett å arbeide etter, ja, men som alle ekspertene våre påpekte på en eller annen måte, trenger team og organisasjoner fortsatt agile arbeidsflytprosesser og prosedyrer for å få ting gjort. Til syvende og sist er det hvordan mennesker bruker agile i praksis, som betyr noe.
Informatikeren Allen Holub oppsummerer det ganske treffende:
Agil kultur er også viktig
Galen Low, medgrunnlegger av DPM, understreker at en agil kultur også er viktig, utover selve det agile tankesettet: «Det vi må huske om Agile, er at Agile-manifestet utløste en revolusjon i måten programvareutviklingsprosjekter ble gjennomført på rundt 2001.
«Nå som det har gått over 20 år, tar vi den opprørske og innovative ånden i det hele for gitt, og vi blir sittende fast i et forsøk på å se om vi følger alle reglene riktig. Det fantes ingen regler i manifestet, bare veiledende prinsipper og felles verdier,» sier han. «Agilt arbeid er en kultur like mye som det er en tankegang.»
I en nylig podkastepisode med Dave Prior gjentok Prior, en seniorkonsulent hos Leading Agile, noe lignende, med spesifikk henvisning til smidige byråer: «Folk snakker hele tiden om kultur i forbindelse med smidig arbeid, som om man må lede med kultur og at kultur er veldig viktig, men hvis du ikke skaper et miljø der noe som Scrum kan overleve, kommer det ikke til å fungere … Hvis du ikke skaper rommet det kan vokse i, kommer det ikke til å fungere.»
Vårt offisielle syn: Smidig arbeid er en tankegang (og mer)
Så ja, smidig arbeid er en tankegang, men det er også en kultur og et miljø som alle på teamet må slutte opp om for at det skal fungere.
Det er først og fremst ikke en metode alene. Uten den smidige tankegangen og kulturen mister smidige prosesser sin tiltenkte verdi.
Som Shaughnessy påpeker: «Det er nyttig å omfavne smidig arbeid … Det bringer team sammen. Det styrker kommunikasjon og muligheter, ser fordelene ved å mislykkes og tar utgangspunkt i sluttbrukernes behov, som tross alt er alt vi prøver å oppnå: å bygge produkter som møter brukernes behov på en gjennomtenkt og intuitiv måte.»
Hva synes du?
Ser du på smidig arbeid som en metode eller en tankegang? Det større spørsmålet her er kanskje om smidig arbeid faktisk er bra (og det finnes ingen mangel på debatt om dette heller).
Hvis du vil lese mer om de store spørsmålene innen prosjektledelse, kan du abonnere på nyhetsbrevet fra The Digital Project Manager eller bli med andre digitale prosjektledere i Slack-fellesskapet vårt for å fortsette samtalen!
