Når Scrum ikke er svaret

Scrum er blitt en de facto-standard for smidig utvikling i mange virksomheter, men Scrum er ikke svaret på alt.

Siden Scrum er et av de mest populære (om ikke de mest populære) smidige rammeverket / metodologien, ønsker organisasjoner å ta i bruk metoden slik at de kan høste de antatte fordelene ved å være «smidige».

    Jeg regner meg selv som en fan av smidig tilnærming og Scrum-rammeverket. Jeg setter pris på prinsippene som er en del av Scrum: Å oppdatere programvaren ofte, med flere funksjoner og bedre funksjonalitet levert jevnlig til brukerne.  Jeg liker også måten arbeidet bli målt og analysert over tid og ikke minst demoene for å se resultatet av arbeidet som er utført i en sprint.

      Når Scrum ikke er det riktige svaret

      Men selv om Scrum er et flott rammeverk for programvareutvikling, er det ikke riktig for alle IT prosjekter. Scrum er en utviklingsmetodikk som først og fremst er ideell for nye eller relativt nye produkter, men la oss for eksempel tenke oss et prosjekt som skal bytte ut gammel teknologi.  Ettersom det kan være risiko for driftsproblemer eller støtten for den gamle teknologien kan være tidsbegrenset, kan behovet for å fullføre prosjektet på tid ikke bare være et ønske, men en absolutt nødvendighet. Slike prosjekter har ofte en «deadline» bestemt av en kombinasjon av lisenser og teknologiproblemer.

        Hvorfor passer ikke Scrum?

        Eksempelet over er et typisk eksempel på prosjekter som har et begrenset budsjett og ofte knapt med tid til å komme i mål innen fristen. Selv om dette ikke nødvendigvis eliminerer muligheten til å jobbe i små iterasjoner er det gitt at implementeringen blir som en leveranse, og man mister effekten av hyppige oppdateringer og tilbakemeldinger. Slike prosjekter er egentlig ikke en adopsjon av smidige metoder.

          Se også : Valg av riktig metode kan redusere risiko.

            Hva er alternativet?

            Når tid og budsjett er den største utfordringen for prosjektet kan en mulig tilnærming være:

            • Skriv brukerhistorier (for å definere funksjonalitet og regler)
            • Angi kompleksitet til hver historie  (for å avstemme forventninger)
            • Organiser og prioriter arbeidet som skal utføres
            • Sett opp en Kanban tavle med de ulike oppgavene 
            Eksempel: Kanban tavle

            Denne arbeidsflyten bygger på prinsippene fra Kanban, og målet er å holde en optimal progresjon på arbeidet.  Tross alt er førsteprioritet å komme i mål innen den angitte fristen. Det kan forøvrig diskuteres om TEST og REVIEW burde bytte plass på tavlen?  Avhengig av prosjektet finnes det argumenter for begge deler.

              Se også : Når Kanban er det beste valget.

                Produkter som er et stykke ut sin livssyklus har en tendens til å favorisere andre tilnærminger enn Scrum, som Kanban, eller til og med fossefall. Disse metodene har også en tendens til å fungere bedre når for eksempel komplekse applikasjoner skal installeres på PCer eller servere. Dette fordi konseptet med et potensielt leverbart produkt på slutten av hver sprint ofte ikke er praktisk gjennomførbart. I stedet kreves en arbeidsflyt med fokus på regresjon og stabilitetstesting.

                  Scrum har sine verdier og sine fordeler, men bare hvis det brukes riktig i prosjektet. En Scrum-prosess vil ikke gi de forventede resultatene hvis den blir tvunget til å tilpasse seg et prosjekt – eller omvendt.

                    Legg igjen en kommentar

                    Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *