ݺߣ

ݺߣShare a Scribd company logo

Alltid smidig når du går?

•Download as PPTX, PDF•
•
Smidigkonferansen
Smidigkonferansen

Under hvilke forutsetninger fungerer smidig best? Professor Magne Jørgensen på Simula Metropolitan og UiO

1 of 24
Download to read offline
Alltid smidig når du går? Hvordan smidighet og selvorganisering påvirker suksess (Nye og tidligere resultater fra HIT-nettverkets undersøkelser) Magne Jørgensen Simula Metropolitan Center for Digital Engineering
Vi analyserte sammenhengen mellom utfallet av IT-utvikling og følgende faktorer: • Utviklingsmetode • Kontrakttype • Kravstabilitet • Prosjektstørrelse • Nyttestyring • Selvorganisering Tilnærming: Suksess og problem-mønstre, ikke så mye enkeltfaktorer
Undersøkelsene • Fire undersøkelser – Informasjon om deres siste prosjekt – 60-150 prosjekter i hver undersøkelse – Fra både kunde og leverandørsiden • En intervju-basert undersøkelse av 32 offentlige utviklingsprosjekter • Prosjektdata fra en “offshoring markedsplass” – Mer enn 400.000 prosjekter/oppgaver, de fleste svært små
SELVORGANISERENDE TEAM … ”THE TEAM HAS SUBSTANTIAL FREEDOM IN SELECTING, SCHEDULING, PROCESSING AND/OR COMPLETING TASKS”
Ikke helt nytt – kanskje den mest opprinnelige måten å jobbe på
Men passer ikke til alle typer oppgaver Her: Organisering av arbeidet med bygging av pyramider (Giza) Conways low (utvidet): Organisasjonsstrukt uren påvirker produktet, og produktet påvirker organisasjons- strukturen. Pyramidebygging med autonome team (mer enn 10.000 arbeidere), ingen klar arkitektur, ingen standardisering av hvordan man jobber og uten detaljerte planer vil være risikabelt og lite produktivt.
ER SYSTEMUTVIKLING MER SOM JAKT ELLER SOM PYRAMIDEBYGGING? (= GJØR AUTONOME TEAM DET STORT SETT BEDRE ELLER DÅRLIGERE?) MANGE PÅSTANDER OM AUTONOME TEAM. IKKE TRO PÅ PÅSTANDER SOM MANGLER EMPIRISKE DATA.
Ender vi for eksempel opp med (autonome) team som kjemper mot hverandre (som i en rugby scrum)
Design av undersøkelse om selvorganiserende team (upublisert) • 101 software-prosjekter (det siste prosjekt respondent hadde deltatt i) • Spørsmål ”Har prosjektet, etter din mening, hatt selv- organiserte team?”: Ja, nei, vet ikke (vet ikke svarene fjernet fra analysen) – Stor forenkling: Optimalt burde vi spurt om på hvilke måter de var selvorganiserende • 45% svarte at teamene var selvorganiserende • Leverandørsiden oppfattet mye flere av teamene til å være selvorganiserende (73 vs 23%) – Uklart hvorfor …
Her er det vi fant ... • Selvorganiserende team (gjennomsnittsverdier) – Ble hyppigere brukt for mindre prosjekter (2.3 vs. 3.0, skala fra 1 til 4, hvor 1 = Liten (0.1-1 mill Euro) og 4 = stor (> 10 mill Euro) – Var oppfattet å være noe mer smidige (2.5 vs 2.8, skala fra 1= svært smidig til 5=ikke smidig i det hele tatt) og brukte to flere smidige praksiser – Hadde litt mindre kundeinvolvering (1.9 vs 1.8, skala fra 1=”svært involvert” to 4=”ikke mye involvert”). – Hadde sjeldnere en detaljert prosjektplan (40% vs 60%). – Hadde samme grad av kravendringer (1.9 vs 2.0, hvor 1=svært mye og 4=svært lite/ikke noe) og samme bruk av kontrakter.
Mer viktig: Gjorde de selvorganiserende teamene det bedre?
Ja! Særlig ved bruk av smidig med hyppige leveranser til kunde Smidig = Oppfattet som “svært smidig”/”smidig”, og mer enn fire leveranser per år. "Acceptable” = Oppfattet som akseptabel eller bedre mhp nytte, kostnads- og tidskontroll “Successful” = Oppfattet som suksess eller bedre mhp nytte, kostnads- og tidskontroll
Hva med skalering? Fører selvorganiserende team til kaos for store prosjekter?
Synes å skalere veldig bra ... Small = < 1 mill Euro, Medium = 1-10 mill Euro, Large = > 10 mill Euro
Andre resultater om smidig- utvikling fra våre undersøkelser
Undersøkelse av 63 norske IT- prosjekter
“Smidig” er ikke smidig … Prosentene viser økning (I prosentpoeng) I andel suksessfulle prosjekter Smidig var kun forbundet mer mer prosjektsuksess når det inkluderte hyppige leveranser til produksjon og fleksibelt innhold Uten dette, færre suksesser enn ikke-smidige prosjekter. Smidig - generelt Smidig med hyppige leveranser til produksjon/evaluering Flekisbelt innhold Kundenytte 16% 22% 29% Teknisk kvalitet 21% 6% 32% Kostnadskontroll 2% 22% 29% Tidskontroll 8% 11% 24% Produktivitet 11% 5% 24% Lignende resultater I oppfølgingsundersøkelser.
Hyppige leveranser særlig viktig i prosjekter med høy hyppighet av kravendringer og tillegg
Smidige prosjekter skalerer bra (overraskende for mange)
Analyse av data om mer enn 400.000 små prosjekter og en dybdestudie av 35 store offentlige prosjekter
Stronger emphasis on low price in selection of provider Lower client/stakeholder involvement in project management Stronger focus on specification and less on what gives the client more benefits Project scope changes and scope flexibility perceived more as a risk Less use of agile development with frequent deliveries to production and flexible scope Lower client involvement in management of resources Less focus on benefit management during the project execution Higher risk of project problems Lower emphasis on provider skill Higher risk of provider and developer skill problems Higher risk of quality or productivity problems Higher risk of client benefits problems Less and late feedback from users and stakeholder Problem-mønster som starter med fastpriskontrakt Higher risk of opportunistic provider behaviour, when making financial loss Higher risk of selection of a provider with price based on over-optimistic effort estimate Fixed price contracts
Stronger emphasis on evaluation of skill, less emphasis on low price, in selection of provider Stronger client and stakeholder involvement in project management Project scope changes and scope flexibility perceived as a an opportunity More use of agile development with frequent deliveries to production and flexible scope Stronger client involvement in management (monitoring, selection) of resources More focus on benefit management during the project execution Higher likelihood of project success Higher likelihood of competent provider and skilled developers Higher likelihood of good quality and productivity Higher likelihood of delivering the expected client benefits More, earlier and better feedback from users and other stakeholder Et mønster for suksess …. Less risk of opportunistic behaviour of provider Time & material contracts
Oppsummert • Empiriske data (om enn ikke veldig sterke) indikerer at autonome team lykkes oftere – Hvorfor og i hvilke sammenhenger trenger mer forskning • Smidig er ikke smidig, og særlig hyppige leveranser til produksjon (med feedback) og fleksibelt innhold synes å være viktig for lykkes. – Særlig når det er mye kravendringer og når prosjektene blir store. • Vi må bli bedre på å forstå ”mønstre” og ikke bare suksess og fiasko-faktorer. Det er her vi finner det mest nyttige resultatene.
SPØRSMÅL? Last ned vår nye bok om estimering på: tinyurl.com/timepredictions

More Related Content

Alltid smidig når du går?

  • 1. Alltid smidig når du går? Hvordan smidighet og selvorganisering påvirker suksess (Nye og tidligere resultater fra HIT-nettverkets undersøkelser) Magne Jørgensen Simula Metropolitan Center for Digital Engineering
  • 2. Vi analyserte sammenhengen mellom utfallet av IT-utvikling og følgende faktorer: • Utviklingsmetode • Kontrakttype • Kravstabilitet • Prosjektstørrelse • Nyttestyring • Selvorganisering Tilnærming: Suksess og problem-mønstre, ikke så mye enkeltfaktorer
  • 3. Undersøkelsene • Fire undersøkelser – Informasjon om deres siste prosjekt – 60-150 prosjekter i hver undersøkelse – Fra både kunde og leverandørsiden • En intervju-basert undersøkelse av 32 offentlige utviklingsprosjekter • Prosjektdata fra en “offshoring markedsplass” – Mer enn 400.000 prosjekter/oppgaver, de fleste svært små
  • 4. SELVORGANISERENDE TEAM … ”THE TEAM HAS SUBSTANTIAL FREEDOM IN SELECTING, SCHEDULING, PROCESSING AND/OR COMPLETING TASKS”
  • 5. Ikke helt nytt – kanskje den mest opprinnelige måten å jobbe på
  • 6. Men passer ikke til alle typer oppgaver Her: Organisering av arbeidet med bygging av pyramider (Giza) Conways low (utvidet): Organisasjonsstrukt uren påvirker produktet, og produktet påvirker organisasjons- strukturen. Pyramidebygging med autonome team (mer enn 10.000 arbeidere), ingen klar arkitektur, ingen standardisering av hvordan man jobber og uten detaljerte planer vil være risikabelt og lite produktivt.
  • 7. ER SYSTEMUTVIKLING MER SOM JAKT ELLER SOM PYRAMIDEBYGGING? (= GJØR AUTONOME TEAM DET STORT SETT BEDRE ELLER DÅRLIGERE?) MANGE PÅSTANDER OM AUTONOME TEAM. IKKE TRO PÅ PÅSTANDER SOM MANGLER EMPIRISKE DATA.
  • 8. Ender vi for eksempel opp med (autonome) team som kjemper mot hverandre (som i en rugby scrum)
  • 9. Design av undersøkelse om selvorganiserende team (upublisert) • 101 software-prosjekter (det siste prosjekt respondent hadde deltatt i) • Spørsmål ”Har prosjektet, etter din mening, hatt selv- organiserte team?”: Ja, nei, vet ikke (vet ikke svarene fjernet fra analysen) – Stor forenkling: Optimalt burde vi spurt om på hvilke måter de var selvorganiserende • 45% svarte at teamene var selvorganiserende • Leverandørsiden oppfattet mye flere av teamene til å være selvorganiserende (73 vs 23%) – Uklart hvorfor …
  • 10. Her er det vi fant ... • Selvorganiserende team (gjennomsnittsverdier) – Ble hyppigere brukt for mindre prosjekter (2.3 vs. 3.0, skala fra 1 til 4, hvor 1 = Liten (0.1-1 mill Euro) og 4 = stor (> 10 mill Euro) – Var oppfattet å være noe mer smidige (2.5 vs 2.8, skala fra 1= svært smidig til 5=ikke smidig i det hele tatt) og brukte to flere smidige praksiser – Hadde litt mindre kundeinvolvering (1.9 vs 1.8, skala fra 1=”svært involvert” to 4=”ikke mye involvert”). – Hadde sjeldnere en detaljert prosjektplan (40% vs 60%). – Hadde samme grad av kravendringer (1.9 vs 2.0, hvor 1=svært mye og 4=svært lite/ikke noe) og samme bruk av kontrakter.
  • 11. Mer viktig: Gjorde de selvorganiserende teamene det bedre?
  • 12. Ja! Særlig ved bruk av smidig med hyppige leveranser til kunde Smidig = Oppfattet som “svært smidig”/”smidig”, og mer enn fire leveranser per år. "Acceptable” = Oppfattet som akseptabel eller bedre mhp nytte, kostnads- og tidskontroll “Successful” = Oppfattet som suksess eller bedre mhp nytte, kostnads- og tidskontroll
  • 13. Hva med skalering? Fører selvorganiserende team til kaos for store prosjekter?
  • 14. Synes å skalere veldig bra ... Small = < 1 mill Euro, Medium = 1-10 mill Euro, Large = > 10 mill Euro
  • 15. Andre resultater om smidig- utvikling fra våre undersøkelser
  • 16. Undersøkelse av 63 norske IT- prosjekter
  • 17. “Smidig” er ikke smidig … Prosentene viser økning (I prosentpoeng) I andel suksessfulle prosjekter Smidig var kun forbundet mer mer prosjektsuksess når det inkluderte hyppige leveranser til produksjon og fleksibelt innhold Uten dette, færre suksesser enn ikke-smidige prosjekter. Smidig - generelt Smidig med hyppige leveranser til produksjon/evaluering Flekisbelt innhold Kundenytte 16% 22% 29% Teknisk kvalitet 21% 6% 32% Kostnadskontroll 2% 22% 29% Tidskontroll 8% 11% 24% Produktivitet 11% 5% 24% Lignende resultater I oppfølgingsundersøkelser.
  • 18. Hyppige leveranser særlig viktig i prosjekter med høy hyppighet av kravendringer og tillegg
  • 19. Smidige prosjekter skalerer bra (overraskende for mange)
  • 20. Analyse av data om mer enn 400.000 små prosjekter og en dybdestudie av 35 store offentlige prosjekter
  • 21. Stronger emphasis on low price in selection of provider Lower client/stakeholder involvement in project management Stronger focus on specification and less on what gives the client more benefits Project scope changes and scope flexibility perceived more as a risk Less use of agile development with frequent deliveries to production and flexible scope Lower client involvement in management of resources Less focus on benefit management during the project execution Higher risk of project problems Lower emphasis on provider skill Higher risk of provider and developer skill problems Higher risk of quality or productivity problems Higher risk of client benefits problems Less and late feedback from users and stakeholder Problem-mønster som starter med fastpriskontrakt Higher risk of opportunistic provider behaviour, when making financial loss Higher risk of selection of a provider with price based on over-optimistic effort estimate Fixed price contracts
  • 22. Stronger emphasis on evaluation of skill, less emphasis on low price, in selection of provider Stronger client and stakeholder involvement in project management Project scope changes and scope flexibility perceived as a an opportunity More use of agile development with frequent deliveries to production and flexible scope Stronger client involvement in management (monitoring, selection) of resources More focus on benefit management during the project execution Higher likelihood of project success Higher likelihood of competent provider and skilled developers Higher likelihood of good quality and productivity Higher likelihood of delivering the expected client benefits More, earlier and better feedback from users and other stakeholder Et mønster for suksess …. Less risk of opportunistic behaviour of provider Time & material contracts
  • 23. Oppsummert • Empiriske data (om enn ikke veldig sterke) indikerer at autonome team lykkes oftere – Hvorfor og i hvilke sammenhenger trenger mer forskning • Smidig er ikke smidig, og særlig hyppige leveranser til produksjon (med feedback) og fleksibelt innhold synes å være viktig for lykkes. – Særlig når det er mye kravendringer og når prosjektene blir store. • Vi må bli bedre på å forstå ”mønstre” og ikke bare suksess og fiasko-faktorer. Det er her vi finner det mest nyttige resultatene.
  • 24. SPØRSMÅL? Last ned vår nye bok om estimering på: tinyurl.com/timepredictions

Editor's Notes

  • #2: 20 minutes
  • #5: The definition: The degree to which the task provides substantial freedom, independence, and discretion in scheduling the work and in determining the procedures to be used in carrying it out’’ (Hackman&Oldham, 1980, p. 79). «The team owns the task»
  • #7: Si noe mer om hvordan organisasjonen påvirker det man lager, og hvordan det man lager påvirker hvordan man organiserer.
  • #16: Picture illustrates the question: Is more agile better?
  • #19: Discuss this relationship. Could be both in volatile contexts and requirement changes caused by the frequent delivery-mode.