DEBATT: Smidig snart 20 år - og mytene lever i beste velgående

[Redaksjonen.]

DEBATT: Smidig snart 20 år - og mytene lever i beste velgående

[_Nils_]

Ingen overraskelse at de som tjener penger på å sitte i prosjektmøter i stedet for å produsere produkter, synes Agile er skremmende...

[Risotto]

En smidig artikkel. Den begynte som reaksjon på en påstand, ble til underveis, for nå var du jo begynt, og ender opp med en tynn konklusjon. Flott, du fikk levert. Neste gang så skriv et mandat til deg selv innen du begynner.

[Anders Jensen]

XP (smidig) for å oppdage og eksperimentere med det ukjente. LEAN (DevOps) for å forvalte de modne produktene fra XP. Prosjekt for å anskaffe tjenester. Det hele faller naturlig ut av Cynefin, men det krever et idè orientert tankesett (hvordan endrer dette systemets oppførsel), ikke et metrikk orientert tankesett (hva får jeg ut av dette) for å forstå disse sammenhengene. Den evnen er ugjevnt fordelt. Det er kanskje årsaken til at folk snakker forbi hverandre og at vi har diffusjonskurven og ikke bare innovatører og tidlige brukere.

Hvis du jobber med prosjekter og er metrikk orientert er det lett å konkludere med at alt annet enn prosjekter er kortsiktig negativt og bør håndteres deretter. En idè orientert tenker vil se at gevinsten på sikt er verdt kortsiktig kostnad.

Et annet element er at IT er en pop kultur, og en bør være skeptisk til alt som er ensidig positivt fremstilt. Simon Wardley har en del balanserte vurderinger av prosjekt, LEAN og smidig. Jeg innledet med konklusjonen hans. Den er fundamentert i grad av usikkerhet. Prosjekt egner seg til oppgaver med lav grad av usikkerhet. Hvis du er en system analytiker så ser du det lett i mengden risiko håndterende teknikker prosjektmetodikken har bygd opp over tid. Dette er kjennetegnet på en workaround. Stor usikkerhet krever raske feedback loops og en distribuert beslutningsprosess slik en ser i militære kampavdelinger med autonome team, og nå senere innen software utvikling. Oppgaver med lav usikkerhet får for dårlig effektivitet med lite og fragmentert planlegging. Derfor blir det ulønnsomt med smidig metodikk her.

Uansett hva du gjør så trenger du en strategi. Hvis du ikke vet hva du skal oppnå så er det ingen metodikk som hjelper.

Endret 20. november 2020 av Anders Jensen

[Thommy B]

Jeg husker godt diskusjonene vi hadde tidlig om vi burde bruke begrepet Agile eller Smidig. Vi hadde en frykt for at begrepet kom til å bli kommersialisert og således ødelagt. Derfor valgte vi å konsekvent bruke begrepet smidig (smidigkonferansen osv). Vi snakket også mye om hvordan vi kunne skape forståelse av hva smidig grunnleggende er og hjelpe industrien unna dette med rammeverk og metode i større grad.

 

Nå har jo mye modnet hos mange og smidig har vært tildels mainstream en stund, med den risikoen at det vil være forvirring og opportunistiske rammeverk der ute som gir deg en "silver bullet". Min erfaring så langt har vært at vi alltid kommer tilbake til røttene når vi kommer ned i teamet og sammen med folkene som jobber i de.

 

Vi leverer kvalitet for både kunde og oss selv i iterasjoner og vi forbedrer oss hver gang. Dette kan gjøres i prosjekt og utenfor. Det er en del do's and don'ts fra erfaring (og verktøy) de siste 10-20 årene som gir oss bedre mulighet for å raskere få resultater. Min erfaring har vært at fasilitering og tilrettelegging er nøkkelen og styring har motsatt virkning. Jeg har også sett bevis på at når man fokuserer for mye på tankesett og for lite på praksis så kan man ende opp i en "Agile is a mindset" kultur hvor man ikke gjør noe praktisk for å lære, ta en risk eller feile, for eksempel teste et rammeverk og se om det fungerer. Det er ikke enklere å levere på en smidig måte, det er vanskeligere fordi du gjør så mye mer enn kun å lage et produkt eller tjeneste.

 

For meg er smidig alle disse tingene; bygge team, bygge mindset, bygge praksis, bygge produkter hver gang om det er i prosjekt eller linja.

Endret 20. november 2020 av Thommy B

[Geir Amsjø]

Godt skrevet! Og du har selvsagt rett i at det går an å levere veldig solide og bra saker i prosjekter. Det sentrale mener jeg er et sterkt eierskap i teamene, og da er det en forutsetning at de som gjør jobben har et langsiktig perspektiv og at de virkelig bryr seg om både produktets kvalitet og brukerne. Og at de har frihet til å gjøre selvstendige valg - dvs at ingen styrer dem for sterkt. Dette eierskapet svekkes hvis de vet at de skal levere produktet over til noen andre (forvaltning) når prosjektet er ferdig.