En introduksjon til Scrum

1. En introduksjontil Scrum <ditt navn> <dato>

2. En introduksjon til Scrum Presentert av <deg> <dato>

3. “The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.” Hirotaka Takeuchi og Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review,januar 1986. Vi taper stafetten

4. Scrum på 100 ord • Scrum er en smidig prosess som lar oss fokusere på å levere høyest mulig forretningsverdi på kortest mulig tid. • Scrum lar oss raskt og regelmessig inspisere fungerende programvare (i perioder fra to til fire uker). • Bedriften setter prioritetene. Teamene organiserer seg selv for å finne den beste måten å levere den høyest prioriterte funksjonaliteten. • I hver periode fra to til fire uker – en sprint – kan alle se fungerende programvare, og avgjøre om det kan slippes eller om man skal fortsette å utvikle det i en sprint til.

5. Scrums opprinnelse • Jeff Sutherland • Innledende scrum på Easel Corp i 1993 • IDX og 500+ folk bruker Scrum • Ken Schwaber • ADM • Presenterte Scrum på OOPSLA 95 med Sutherland • Forfatter av tre bøker om Scrum • Mike Beedle • Scrum-mønstre i PLOPD4 • Ken Schwaber og Mike Cohn • Stiftet Scrum Alliance i 2002, opprinnelig innenfor Agile Alliance

6. Scrum har blitt brukt av: • Microsoft • Yahoo • Google • Electronic Arts • Lockheed Martin • Philips • Siemens • Nokia • IBM • Capital One • BBC • Intuit • Nielsen Media • First American Real Estate • BMC Software • Ipswitch • John Deere • Lexis Nexis • Sabre • Salesforce.com • Time Warner • Turner Broadcasting • Oce

7. Scrum har blitt brukt til: • Kommersiell programvare • Intern utvikling • Kontraktsutvikling • Prosjekter med avtalt pris • Finansielle applikasjoner • ISO 9001-sertifiserte applikasjoner • Innebygde systemer • 24x7 systemer med krav til 99.999% oppetid • Joint Strike Fighter • Dataspillutvikling • FDA-godkjente, livskritiske systemer • Kontrollsystemer for satellitter • Websider • Programvare for håndholdte enheter • Mobiltelefoner • Nettverksapplikasjoner • Applikasjoner fra uavhengige programvareleverandør • Noen av de største applikasjonene i bruk

8. Kjennetegn • Selvorganiserende team • Produktene utvikles i “sprinter” (perioder på to til fire uker) • Krav blir presentert som punkter på en liste (product backlog) • Ingen spesifikke tekniske arbeidsmåter blir foreskrevet • Bruker produktive regler for å skape et smidig miljø for å levere prosjekter • Én av de ”smidige prosessene”

9. Personer og samspill Å reagere på endringer Programvare som virker Samarbeid med kunden Å følge en plan Omfattende dokumentasjon Kontraktsforhandlinger Prosesser og verktøy fremfor fremfor fremfor fremfor The Agile Manifesto – et sett med verdier Kilde: www.agilemanifesto.org

10. Et prosjekts støynivå Langt unna avtale Anarki Kompleks Krav Vanskelig Kilde: Strategic Management and Organizational Dynamics av Ralph Stacey i Agile Software Development with Scrum av Ken Schwaber og Mike Beedle. Enkelt Nær avtale Teknologi Nær sikker Langt unna sikker

11. 24 timer Sprint-mål Gift wrap Gift wrap Coupons Coupons Return Cancel Cancel Sprint backlog Sprint 2-4 uker Return Potensielt leverbart produktinkrement Scrum Product backlog

12. Alt sett i sammenheng Bilde tilgjengelig på www.mountaingoatsoftware.com/scrum

13. Sprintene • Scrum-prosjekter utvikles i en serie av sprinter • Tilsvarende iterasjoner i Extreme Programming • Typisk varighet er to til fire uker, eller maks én kalendermåned • En fast varighet fører til bedre rytme • Produktet designes, kodes og testes i løpet av sprinten

14. Sekvensiell kontra overlappende utvikling Krav Design Kode Test I stedet for å gjøre en ting om gangen... ...gjør Scrum-team litt av alt hele tiden Kilde: “The New New Product Development Game” av Takeuchi og Nonaka. Harvard Business Review, januar 1986.

15. Ingen endringer i løpet av en sprint • Planlegg varigheten på en sprint i forhold til hvor lenge du kan binde deg til å ikke gjøre endringer i en sprint Endringer

16. Roller Seremonier Artefakter • Produkteier • ScrumMaster • Teamet • Sprint-planlegging • Sprint-gjennomgang • Sprint-retrospekt • Daglige scrum-møter • Product backlog • Sprint backlog • Burndown-diagram Scrum-rammeverket

17. Seremonier Roller • Sprint-planlegging • Sprint-gjennomgang • Sprint-retrospekt • Daglige scrum-møter • Produkteier • ScrumMaster • Teamet Scrum-rammeverket Artefakter • Product backlog • Sprint backlog • Burndown-diagram

18. Produkteier • Definerer produktets funksjonalitet • Avgjør sperrefrist og innhold • Er ansvarlig for produktets lønnsomhet (ROI) • Prioriterer funksjonalitet i forhold til markedsverdi • Justerer funksjonalitet og prioritet ved hver iterasjon, etter behov • Aksepterer eller forkaster arbeidsresultater

19. ScrumMaster • Representerer ledelsen ovenfor prosjektet • Ansvarlig for å opprettholde Scrum-verdier og -metoder • Fjerner hindringer • Passer på at teamet er funksjonelt og produktivt • Muliggjør tett samarbeid mellom rollene og funksjonene • Skjermer teamet fra eksterne inngrep

20. Teamet • Normalt 5-9 personer • Tverrfunksjonelt: • Utviklere, testere, interaksjonsdesignere osv. • Medlemmene bør være på heltid • Kan være unntak (f.eks. databaseadministrator) • Teamene er selvorganiserende • Ingen titler er ideelt, men sjelden en mulighet • Teamsammensetning bør kun endres mellom sprinter

21. Roller Artefakter Seremonier • Produkteier • ScrumMaster • Teamet • Product backlog • Sprint backlog • Burndown-diagram • Sprint-planlegging • Sprint-gjennomgang • Sprint-retrospekt • Daglige scrummøter Scrum-rammeverket

22. Sprint-prioritering Sprint-planlegging Sprint-mål Sprint backlog • Analysere og evaluere produkt backlog • Velge sprint-mål • Bestem hvordan sprint-målet kan nås (design) • Lag sprint backlog (oppgaver) fra punkter i product backlog (user stories / funksjonalitet) • Estimere sprint backlog i timer Sprint-planleggingsmøte Teametskapasitet Produkt backlog Forretnings- betingelser Gjeldendeprodukt Teknologi

23. Kode forretningslogikklaget (8 timer) Kode brukergrensesnittet (4) Skriv testklasser (4) Kode foo-klassen (6) Oppdatere ytelsestester (4) Sprint-planlegging • Teamet velger punkter fra product backlog de kan binde seg til å fullføre • En sprint backlog blir opprettet • Oppgavene blir identifisert og hver av dem blir estimert (1-16 timer) • Gjøres i fellesskap, ikke av ScrumMaster alene • Design på et overordnet nivå blir vurdert Som en ferieplanlegger vil jeg se bilder av hotellet.

24. Daglig scrum-møte • Parametre • Daglig • 15-minutter • Stående • Ikke for problemløsing • Hele verden er invitert • Bare teammedlemmer, ScrumMaster og produkteier kan prate • Hjelper til å unngå andre unødvendige møter

25. 1 2 3 Hva gjorde du i går? Hva skal du gjøre i dag? Hindrer noe deg i arbeidet? Alle svarer på 3 spørsmål • Det er ikke statusrapportering til ScrumMaster • Det er forpliktelser ovenfor kolleger

26. Sprint-gjennomgang • Teamet presenterer det som ble utført i sprinten • Gjøres ofte som en demo av ny funksjonalitet eller underliggende arkitektur • Uformelt • 2 timer forberedelsestid • Ingen PowerPoint-sider • Hele teamet deltar • Inviter hele verden

27. Sprint-retrospekt • Regelmessig vurdering av hva som fungerer og ikke fungerer • Typisk 15 - 30 minutter • Gjøres etter hver sprint • Hele teamet deltar • ScrumMaster • Produkteier • Teamet • Eventuelt kunder og andre

28. Dette er kun én av mange måter å gjøre sprint-retrospekt på. Begynne / Slutte / Fortsette • Hele teamet møtes og diskuterer hva de vil: Begynne å gjøre Slutte å gjøre Fortsette å gjøre

29. Roller Seremonier Artefakter • Produkteier • ScrumMaster • Teamet • Sprint-planlegging • Sprint-gjennomgang • Sprint-retrospekt • Daglige scrummøter • Product backlog • Sprint backlog • Burndown-diagram Scrum-rammeverket

30. Product backlog • Krav • En liste over alt ønsket arbeid i prosjektet • Beskrevet slik at hvert punkt har verdi for produktets brukere eller kunder • Prioriteres av produkteier • Reprioriteres før hver sprint Dette er product backlog

31. Product backlog-eksempel

32. Sprint-målet • En kort beskrivelse over hva som har fokus i denne sprinten Biovitenskap Støtte nødvendig funksjonalitet for genetiske studier. Databaseapplikasjonen Applikasjonen skal kjøre på SQL Server i tillegg til Oracle. Finansielle tjenester Støtte flere tekniske indikatorer enn ABC med sanntidsdata.

33. Håndtere sprint backlog • Personer tar på seg arbeid etter eget ønske • Arbeid er aldri avtalt/utpekt • Estimert gjenstående arbeid oppdateres daglig • Ethvert teammedlem kan legge til, fjerne eller endre oppgaver i sprint backlog • Nye oppgaver vil oppdages underveis i sprinten • Hvis arbeidet er uklart kan man definere en oppgave i sprint backlog med et høyere estimat og dele det opp senere • Oppdater gjenstående arbeid etterhvert som man vet mer

34. 4 8 8 16 12 4 10 8 11 8 16 16 12 8 8 8 8 8 Legg til feilregistrering 4 8 En sprint backlog Oppgaver Man Tirs Ons Tors Fre Kode brukergrensesnitt Kode mellomlaget Teste mellomlaget Skriv online-hjelp Skriv foo-klassen

35. Et sprint burndown-diagram Timer

36. 8 4 10 7 12 16 8 16 11 Oppgaver Man Tirs Ons Tors Fre Kode brukergrensesnitt 8 Kode mellomlaget 16 Teste mellomlaget 8 Skriv online-hjelp 12 50 40 30 Timer 20 10 0 Man Tirs Ons Tors Fre

37. Skalerbarhet • Normalt 7 ± 2 personer per team • Skalerbarhet gjennom team av team • Faktorer i skalering • Applikasjonstype • Teamets størrelse • Teamets spredning • Prosjektets varighet • Scrum har blitt brukt på flere prosjekter med 500+ deltakere

38. Skalering gjennom Scrum of scrums

39. Scrum of scrums of scrums

40. Hvor kan man finne ut mer • www.mountaingoatsoftware.com/scrum • www.scrumalliance.org • www.controlchaos.com • scrumdevelopment@yahoogroups.com

41. Litteratur om Scrum • Agile and Iterative Development: A Manager’s Guide av Craig Larman • Agile Estimating and Planning av Mike Cohn • Agile Project Managementwith Scrum av Ken Schwaber • Agile Retrospectives av Esther Derby og Diana Larsen • Agile Software Development Ecosystems av Jim Highsmith • Agile Software Development with Scrum av Ken Schwaber og Mike Beedle • Scrum and The Enterprise av Ken Schwaber • User Stories Applied for Agile Software Development av Mike Cohn • Det finnes mange ukentlige artikler på www.scrumalliance.org

42. Lisensvilkår • Du har lov til: • å dele - å kopiere, distribuere og spre verket • å remikse - å bearbeide verket • På følgende vilkår: • Navngivelse - Du skal navngi opphavspersonen og/eller lisensgiveren på den måte som disse angir (men ikke på en måte som indikerer at disse har godkjent eller anbefaler din bruk av verket) • Ingenting i lisensen skader eller begrenser opphavsmannens ideelle rettigheter • For mer informasjon, sehttp://creativecommons.org/licenses/by/3.0/

43. Kontaktinformasjon Presentation by: Mike Cohn mike@mountaingoatsoftware.com www.mountaingoatsoftware.com (720) 890-6110 You can remove this (or any slide) but you must credit the source somewhere in your presentation. Use the logo and company name (as at bottom left, for example) or include a slide somewhere saying that portions (or all) of your presentation are from this source. Thanks.