
De fleste selskaper følger en eller annen form for Scrum-prosess. Vanligvis innebærer dette 2 eller 3 ukers sprinter. På slutten av hver sprint blir endringer demonstrert, retrospektiver gjennomføres og backloggen blir vedlikeholdt. Under hver sprint blir tid for oppgavegjennomføring registrert, noe som lar ledelsen projisere inn i fremtiden når prosjekter vil bli fullført.
Mange av Scrum-prosjektene jeg har vært en del av legger vekt på å “forplikte seg” til oppgaver eller “ta eierskap.” På slutten av sprinten blir mange ingeniører holdt ansvarlige for ufullstendige oppgaver. Sprint-hastighet er en annen idé som blir hamret inn. Vi må holde hastigheten vår! Det er som om å lage programvare er et løp, det er det ikke. Hvis ingeniører blir holdt ansvarlige av en målestokk, vil de optimalisere for målestokken, dette er ikke det du ønsker.
Scrum skaper et lett forståelig rammeverk for team å følge og det gir ledelsen verktøyene til å forutsi fremtiden. Team som har praktisert waterfall finner Scrum lett å forstå.
Mange av Scrums praksiser er ikke nødvendige. For eksempel lar de fleste saksporingsprogramvarer ledere kjøre rapporter om frekvensen av billett-fullføring. Med denne informasjonen kan ledere utlede hastighet, i stedet for å bake hastighet inn i prosessen og gjøre det til en stor sak. Å ta eierskap er en farce, vi gjør det naturlig, å gjøre det eksplisitt er fornærmende. Alle prosjektene jeg har vært en del av har hver ingeniør et hjørne av applikasjonen som er deres område.
Andre måter å forbedre programvareleveranse på:
- Hvis du trenger ukentlige utrullinger, planlegg dem. Rull ut det som er klart.
- Hold backloggen vedlikeholdt; da går ingeniørene aldri tom for arbeid.
- Etter min mening er retrospektiver den mest essensielle ikke-utviklingsaktiviteten. Uten den har du ingen sjanse til å bli en bedre og mer effektiv organisasjon.
- Automatiser, automatiser, automatiser
- Å forplikte seg til en liste med funksjoner er latterlig. Ranger oppgavene og fullfør det du kan. Å bekymre seg over hvorfor “oppgave A” ikke ble fullført er bortkastet tid. Det er klart at oppgaven enten var for stor, eller at arbeid med høyere prioritet ble påtatt.
- Demoer er bortkastet tid med mindre klienten bryr seg og gir tilbakemelding.
- Daglige møter kan være nødvendige eller ikke. Jeg foretrekker å møtes annenhver dag.
Til syvende og sist handler det om å gi verdi til klienten på den mest effektive måten.
Forfatter: Chuck Conway spesialiserer seg på programvareutvikling og Generativ AI. Koble til ham på sosiale medier: X (@chuckconway) eller besøk ham på YouTube.