Smidige Prosjektmetoder whats hot and whats not Presentasjon

Smidige Prosjektmetoder – what’s hot and what’s not? Presentasjon på prosjekt 2007 Kristoffer Kvam, Senior Project Manager, Telenor Nordic Mobile

Agenda 1. Innledning (5 min) 2. Case studies : (15 min) 1. Produktivitetsøkningen. 2. Underleverandøren som aldri leverte. 3. Teamet som drev med scrum til det kjedelige. 4. QA-prosessen som fikk seg et ekstra gir. 3. Sjekkliste – hvordan velge hvilken metode (15 min) 4. Smidige prosjektmetoder – min spådom (5 min)

Case 1 : Produktivitetsøkningen

Krav til testdrevet utvikling Test Rammeverk Nytt konfigurasjonssystem Intervjuprogram for nye konsulenter Ukentlig kunnskapsdelingsmøte Scrum og parprogrammering introdusert

DETALJER • Eksisterende prosesser kan få en vitamininnsprøytning og produktivitetsøkning av slike metoder Prosjekter ble før gjennomført som individuelt arbeid inn i større prosjekter • Innføringen bør være gradvis – gjerne som en del av en iterativ evalueringsprosess. I forkant av oppstarten var det gjennomført et større reengineering-prosjekt der smidige utviklingsmetoder ble levert • 100 % ressurser som tidligere har jobbet individuelt kan helt fint komme inn Innføringen av smidig metodikk ble valgt av miljøet selv! • Smidige utviklingsteknikk koster penger og guts å innføre. Men du verden, det fungerer • Miljø på 40 utviklere/arkitekter i et meget forretningskritisk system • • • LÆRINGSPUNKTER

Case 2 : Underleverandøren som aldri leverte

Hovedprosjekt Delprosjekt Produkt Marked Teknisk Kjernesystemer WEB team Leverer 1/2 år for sent Grad av smidighet: Lav Medium Høy Ekstern leverandør

DETALJER • Utvikling av kjøpsløsning på web • Ekstern partner for kredittkortbehandling • Ingen fra den eksterne partneren inngikk i prosjektet • Delprosjekt teknisk hadde en ”litt for smidig” avtale LÆRINGSPUNKTER • Partnere og eksterne leverandører er blitt en del av nesten et hvert prosjekts økosystem. • En typisk avtale krever mye tydeligere kontrollmekanismer og oppfølging enn interne leverandører • Dersom et team skal jobbe smidig må det være ”Autonomt” • I smidige team på partneren inn i teamet. Smidighet og fleksibilitet må håndteres i kontrakt.

Case 4 : QA-prosessen som fikk et ekstra gir

DETALJER LÆRINGSPUNKTER • Kvalitetssikringsprosessen i et lite smidig prosjekt hadde gått i stå • Daglige Standup møter (ref Scrum) er et utrolig effektivt verktøy for å få attention rundt en sak. • Det var kort tid til lansering og brukertester viste at det trengtes endringer. Det var også en del grove feil. • Krever at du har representanter som kan løse jobber (ref autonomt). • Krever at medlemmer møter opp hver dag. • Er meget lett å innføre hvis egnet oppgave • Teknisk delprosjektleder hadde et svært strukturert og prinsippfast syn på prosjektledelse. • Hovedprosjektleder innførte daglig standup for alle sentrale stakeholders i markedet. • På 20 dager var man på markedet.

Case 4 : Teamet som drev med Scrum til det kjedelige

Vedlikeholdsteamet hadde holdt på med det samme alt for lenge:

DETALJER Teamet var gått lei: • LÆRINGSPUNKTER • Smidige metoder krever høyere grad av et samlet mål og en fokusert eier. • Det å være en fasiliterende leder krever sin mann. Det krever også en aksept i organisasjonen. • En produkt backlog er nettopp det. En backlog som dreier seg om ett produkt/konsept som skal realiseres. Den må ha høy forankring. • Er det slik at det er endringen i seg selv til smidige metoder som gir effekten? Man satt under daglig standup • Evaluerte ikke • Hadde ikke konkrete samlende oppgaver. • Backlog lagde de selv. Ingen produkteier. • Scrum-master var lei av jobben sin.

Sjekkliste

Lett Medium Vanskelig Daglig Standup Demonstrasjon av løsning ved hver iterasjon Smidig utviklingsmetodikk Iterativ leveranseprosess Product Backlog Fasiliterende prosjektledelse Jevnlig evaluering Selvorganiserende team Produksjonsklar løsning ved hver iterasjon

Når? Lett Medium Vanskelig • Bruk for : fokus, kontroll og kvalitet i leveranser • Test ut for: fart og ny sprut i organisasjonen • Invester i når du mester de andre for : et varig produktmaskineri • Ikke gjør alt på en gang!

Sjekkliste 1: Lett. . • Relativt dedikert oppgaveområde som skal løses Daglig Standup • Gjeng med individer som alle jobber mot denne oppgaven (ikke for mange) • Milepælsstyrt plan Iterativ leveranseprosess • Mulig å bygge inn time-bokser med underaktiveteter i planen • Org. forståelse for at prosjektet lærer underveis og kan endres • Naturlige refleksjonspunkter i planen (milepæler, timebokser) Jevnlig evaluering • Org. forståelse for at dette ikke er ”waste -tid”

Sjekkliste 2: Medium. . Demonstrasjon av løsning ved hver iterasjon • En aktiv eier. • Iterativ prosess på plass. • Prosjekt med naturlige godbiter å vise underveis • Iterativ prosess på plass Product Backlog • Prosjektplan kan deles opp i underaktiviteter med høy detaljeringsgrad • Org. tørr å vike fra GANT-diagrammet. • Aktiv og interessert eier. • 100 % ressurser Selvorganiserende team • Autonome og ansvarliggjorte ressurser • Du tørr å stole på dem!

Sjekkliste 3: Vanskelig. . • Prosjekt som passer det Smidig utviklingsmetodikk • Initiell investering foretatt i systemer • Endrings- og innovasjonvilje blant teknikere • Alle lette og medium-teknikker på plass Fasiliterende prosjektledelse Produksjonsklar løsning ved hver iterasjon • Aktiv eier • Kultur for å ta kollektivt ansvar • Ett team har full kontroll på løsning, miljø og support • Klinkende klare og målbare kvalitetskrav • Team dekker alle disipliner som trengs

Smidige prosjektmetoder – veien videre

Utfordringen til smidige initiativer så langt…. …er at de har vært ”nerdedrevet”…

Framtidens produktutviklingsmetoder vil fokusere på effekter, ikke leveransekravene i seg selv.

Hva betyr det for ditt prosjekt? • Den smidige forankringen må ligge på hovedprosjektnivå for å kunne gi forretningsgevinst. • Mandatet må være tydelig effektdrevet og strategisk bundet. • Leveranser bør være hovedprosjektets ansvar å utforme. • Teamet ditt bør kunne håndtere hele problemdomenet. • Stor grad eksterne stakeholders er ikke å anbefale.

Hovedprosjekt Delprosjekt Produkt Marked Teknisk Kjernesystemer WEB team Ekstern leverandør Grad av smidighet: Lav Medium Høy

• Takk for oppmerksomheten! • kristoffer. kvam@telenor. com • ; )