Smidige Prosjektmetoder – what’s hot and what’s not?

Presentasjon om: "Smidige Prosjektmetoder – what’s hot and what’s not?"— Utskrift av presentasjonen:

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

2 ?

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

4 Case 1 : Produktivitetsøkningen

5 parprogrammering introdusert
Krav til testdrevet utvikling Test Rammeverk Nytt konfigurasjonssystem Scrum og parprogrammering introdusert Intervjuprogram for nye konsulenter Ukentlig kunnskaps- delingsmøte

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

7 Case 2 : Underleverandøren som aldri leverte

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

9 DETALJER LÆRINGSPUNKTER
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 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.

10 Case 4 : QA-prosessen som fikk et ekstra gir

11 DETALJER LÆRINGSPUNKTER
Kvalitetssikringsprosessen i et lite smidig prosjekt hadde gått i stå Det var kort tid til lansering og brukertester viste at det trengtes endringer. Det var også en del grove feil. 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. Daglige Standup møter (ref Scrum) er et utrolig effektivt verktøy for å få attention rundt en sak. 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

12 Case 4 : Teamet som drev med Scrum til det kjedelige

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

14 DETALJER LÆRINGSPUNKTER Teamet var gått lei:
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. 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?

15 Sjekkliste

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

17 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! Medium Vanskelig

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

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

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

21 Smidige prosjektmetoder – veien videre

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

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

24 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.

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

26 Takk for oppmerksomheten!
;)