Moden og modig! Ansvarsfull og fleksibel! Anine Ragnif og Bodil Rabben 13. Mai 2009
Agile Hvorfor? Gjennomsnittlig overskridelse i arbeidsmengde var 24% for prosjektene som benyttet en fleksibel metodikk, sammenlignet med 55% for de som benyttet en sekvensiell metodikk Studier har vist at opptil 70% av total tid i IT-prosjekter benyttes til samarbeid og kommunikasjon I de prosjektene hvor man hadde en daglig interaksjon mellom kunde og leverandør, hadde man gjennomsnittlige overskridelser i arbeidsmengde på 9%. Tilsvarende hadde man overskridelser i arbeidsmengde på 58% i de prosjektene hvor man ikke hadde daglig interaksjon.
Kunde og Leverandør Elementer i Scrum Agile Manifesto Kontrakt
Elementer i Scrum Roller Product Owner Scrum Team ScrumMaster (Stakeholders) Prosesser Sprint Planning Meeting Sprint Daily Scrum Meeting Sprint Review Meeting Sprint Retrospective Meeting Artifakter Vision Product Backlog Sprint Backlog Burndown Chart Bodil Rabben & Anine Ragnif, Mai 2009 4
Product Owner Arbeidsoppgaver Oppretter og jobber kontinuerlig med Product Backlog Prioritere og legge Backlog ut i tid basert på business value eller ROI Deltar i arbeidet med å definere brukerhistorier som kan realiseres i en sprint Styrer mot visjonen og mål for prosjektet og for hver sprint definere delmål Deltar i Daily Scrums, Sprint Planning Meetings og Sprint Reviews og Retrospectives Kontrollerer produktets fremdrift ved avslutningen av hver sprint og har full myndighet til å akseptere eller avvise arbeid som er nedlagt Kan justere kursen av prosjektet ved avslutningen en hver sprint Håndterer ekstern kommunikasjon Terminerer en sprint dersom en drastisk endring av retning er nødvendig Suksesskriterier Product Owner må ha nok tid Være tilstede, delta i arbeidssamlinger, stille forberedt Product Owner må ha myndighet/fullmakt Ta beslutninger og konsekvensene av de Product Owner må være kvalifisert Forstå behov Forstå Agile/Scrum Bodil Rabben & Anine Ragnif, Mai 2009 5
Scrum Master Arbeidsoppgaver Trener - lagspiller fasilitere andre, fremfor å fremheve egen suksess Fjerne hindringer Kommunisere ut/dele information Gi bistand til Product Owner Kommunisere oppdateringer, hindringer, arbeid med backlog, sprint- og releaseplanlegging Legge til rette for selvorganiserende team Legge til rette for at teamet har det de trenger for å gjøre best mulig jobb: Verktøy og kunnskap Kommunikasjon, kommunikasjon, kommunikasjon Suksesskriterier Ansvar for at teamet fungerer Tar tak i utfordringer og sørger for løsning Skjermer teamet fra forstyrrelser Bistå Product Owner Følger opp fart og fokusfaktor til teamet Ta ut forbedringspotensialet Bodil Rabben & Anine Ragnif, Mai 2009 6
Estimering Internt eller eksternt Kunden forventer estimater Mulige gevinster estimerte kostnader Det skjer overruns, forsinkelser og uheldige beslutninger basert på dårlig estimering også i den smidige verden! Derfor er estimering viktig også i den smidige verden!
Planning Poker Excellent for Estimating Business Value
Example: Prioritizing Work Items Value Cost Value / Cost Priority Item A 3 3 1 3 Item B 5 1 5 1 Item C 13 8 1,6 2 Item D 13 20 0,6 4 Item E 8 100 0,1 6 Item F 2 8 0,25 5 First priority is the quick win s!
Eksempel fra et lite, men teknisk komplekst prosjekt hvor teknologi og fart måtte testes ut
Product Owner
NSB Nytt Intranett taskboard I Erfaringer fra et lite, men komplekst Scrum-prosjekt Karen E. Barlaup, 17. april 2009
NSB Nytt Intranett taskboard II Erfaringer fra et lite, men komplekst Scrum-prosjekt Karen E. Barlaup, 17. april 2009
NSB Nytt Intranett team Erfaringer fra et lite, men komplekst Scrum-prosjekt Karen E. Barlaup, 17. april 2009
Eksempel fra Pensjonsprogrammet I NAV, et stort offentlig fossefallsprosjekt
Scrum daglig scrum! Product Backlogg xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx Daglig Scrum Sprint Daglig Scrum (15 min) Hva har du gjort siden i går? Hva skal du gjøre til i morgen? Hvilke hindringer har du? Sprint Backlogg xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx 4 Uker Ny funksjonalitet demonstreres ved avslutning av sprinten Bodil Rabben & Anine Ragnif, Mai 2009 16
Burndown og fart fra brunpapir til system Sprint P6_b Kjempen - Team Burndown Chart Effort Remaining 80 70 60 Per utvikler 50 40 Hours of Effort Remaining 30 20 10 0 07.jan 08.jan 09.jan 10.jan 11.jan 12.jan 13.jan 14.jan 15.jan 16.jan 17.jan 18.jan 19.jan 20.jan 21.jan 22.jan 23.jan 24.jan 25.jan 26.jan 27.jan 28.jan 29.jan 30.jan 31.jan 01.feb 02.feb 03.feb done Sprint P6b Kjempen - Team Burndown Chart Effort Remaining 1200 1000 800 600 Per sprintteam Hours of Effort Remaining 400 200 0 07.jan 08.jan 09.jan 10.jan 11.jan 12.jan 13.jan 14.jan 15.jan 16.jan 17.jan 18.jan 19.jan 20.jan 21.jan 22.jan 23.jan 24.jan 25.jan 26.jan 27.jan 28.jan 29.jan 30.jan 31.jan 01.feb 02.feb 03.feb done 17 Bodil Rabben & Anine Ragnif, Mai 2009
Sprint Demo fra 2 til mange Bodil Rabben & Anine Ragnif, Mai 2009 18
Scrum og kommunikasjon Daily Scrum Sprint MetaScrumsMaster MetaScrums (15 min) 3 ganger pr uke ScrumMasters/Team leder Synkronisering på tvers av programmet Fokus på felles hindringer Uløste hindringer blir rapportert Daily Scrum Infrastruktur Design team Prosjekt X Prosjekt Y Sprint ScrumOfScrumsMaster Daily Scrum Daily Scrum Daily Daily Scrum Sprint Scrum Sprint Sprint Sprint Bodil Rabben & Anine Ragnif, Mai 2009 19
Kunde og Leverandør Elementer i Scrum Agile Manifesto Kontrakt Bodil Rabben & Anine Ragnif, Mai 2009 20
Hovedfilosofien bak Scrum er nettopp at man ikke kan forutse, forstå eller definere utfordringer i et prosjekt fullt ut i forkant at man i stedet skal fokusere på å maksimere teamets evne til å levere raskt og til å være i stand til å håndtere endringer i forutsetninger og kunne justere kursen underveis i prosjektet Bodil Rabben & Anine Ragnif, Mai 2009 21
Norsk oversettelse av Agile Manifesto Manifest for smidig systemutvikling Individer og samspill framfor prosesser og verktøy Fungerende system framfor utførlig dokumentasjon Samarbeid med kunden framfor kontraktsforhandlinger Å tilpasse oss endringer framfor å følge en plan http://agilemanifesto.org/
I den smidige verden. Inspect and adapt Kunden tenker : Demo, kjempebra, da kan jeg ønske meg hva jeg vil! Utviklerne tenker: Demo, kjempebra, da får jeg tilbakemelding og kan forbedre løsningen Suksesskriterier: Dialog, synkronisering, prioritering, funksjonalitet inn/ut av scope dokumenteres Fungerende system framfor utførlig dokumentasjon Å tilpasse oss endringer framfor å følge en plan
I den smidige verden. (2) Kundens tilgjengelighet Kunden tenker : Jeg kan være med litt 50% her og 50% der. Det er jo tross alt Leverandøren som skal levere Leverandøren tenker: Hvor er Kunden??? Suksesskriterie: Tilstedeværelse Individer og samspill framfor prosesser og verktøy
Sprint team I den smidige verden. (3) Kunden tenker : Alt løses i teamet, jeg bare spør de rekker alt! Sprint teamet tenker: Klart jeg skal hjelpe deg, hva ønsker du? Ops jeg rakk ikke Suksesskriterier: Scrummaster skjerme teamet / Product Owner - bevisst Kjøreregler - estimering konsekvenser prioritering Å tilpasse oss endringer framfor å følge en plan Individer og samspill framfor prosesser og verktøy
Kunde og Leverandør Elementer i Scrum Agile Manifesto Kontrakt
I den smidige verden. (4) Kravene er overordnet Kunden tenker : Puh så slipper jeg å bruke tid på detaljering av krav Leverandøren tenker: Hvordan skal dette estimeres? Suksesskriterier: Dialog i forhandlinger, håndtere krav og omfang, prioritering, forstå konsept (POC, forprosjekt) Samarbeid med kunden framfor kontraktsforhandlinger
Kontrakt Visjon, effektmål og gevinstønsker tydelige Mål: vinn-vinn for Kunde og Leverandør Kunden velger metodikk og verdisyn - bevisst kunde, likhet i tilbud Kunden gir overordnede behov mindre innsats 2008 Capgemini. All rights reserved 28
Kontrakt Visjon, effektmål og gevinstønsker tydelige Leverandørene løser oppgaven (tilbud) => Mye innsats for å forstå behov og kompleksitet => Kunden må bidra mer i dialog med hver leverandør => Sprinter og demoer I behovsfasen Sterkere kunde leverandør samarbeid Bedre behovsforståelse Mer treffsikkerhet i løsning, omfang og tid
Ja, hva kreves? En moden og modig kunde! behov, prioritering, backlog ut inn, endringer, deltagelse Løsningen ble annerledes! Men Dekkes -> Visjon, effektmål og gevinstønsker? En ansvarsfull og fleksibel Leverandør! Fleksibel, hva gir verdi? ønske om andre løsninger Leveranseansvaret ligge på Leverandør Samarbeid, deltagelse, lytt til kunden Ta ansvar!
Hva kreves egentlig av kunde og leverandør for å sikre en vellykket prosjektgjennomføring ved hjelp av agile metoder? Moden og modig kunde! Ansvarsfull og fleksibel leverandør!
www.se.capgemini.com