Agile in non agile environment

1. Erfaringer fra innføring av
smidige metoder i store
prosjekter
Tobias K Torrissen
CTO, Know It

2. Tobias K Torrissen
6 års erfaring fra smidig utvikling
Store prosjekter i telekom og
transport
Scrummaster, arkitekt og utvikler

4. Stort mellomvaresystem
som server et førtitalls
klienter

5. Stort mellomvaresystem
som server et førtitalls
klienter
Del av lang verdikjede

6. Stort mellomvaresystem
som server et førtitalls
klienter
Del av lang verdikjede
4 releaser i året

7. Stort mellomvaresystem
som server et førtitalls
klienter
Del av lang verdikjede
4 releaser i året
Vedlikeholdsteam

8. Stort mellomvaresystem
som server et førtitalls
klienter
Del av lang verdikjede
4 releaser i året
Vedlikeholdsteam
Flere prosjektteam

9. Stort mellomvaresystem
som server et førtitalls
klienter
Del av lang verdikjede
4 releaser i året
Vedlikeholdsteam
Flere prosjektteam

11. Kortere time 2 market
Endringsdyktighet
Høyere kvalitet
Lavere pris

13. 2003 - Testdrevet

14. 2003 - Testdrevet
2004 - Scrum

15. 2003 - Testdrevet
2004 - Scrum
2005 - Flere Scrum team

16. 2003 - Testdrevet
2004 - Scrum
2005 - Flere Scrum team
2007 - Strengere krav til
team

17. 2003 - Testdrevet
2004 - Scrum
2005 - Flere Scrum team
2007 - Strengere krav til
team
2009 - Kanban i
forvaltning

18. Prosjektgjennomføring

19. Prosjektgjennomføring
1
Forslag

20. Prosjektgjennomføring
1 2
Forslag Analyse

21. Prosjektgjennomføring
1 2 3
Forslag Analyse Impl og test

22. Prosjektgjennomføring
1 2 3 4
Forslag Analyse Impl og test Prodsetting

23. Prosjektgjennomføring
1 2 3 4 5
Forslag Analyse Impl og test Prodsetting Gevinst

24. Prosjektgjennomføring
Agile praksis
1 2 3 4 5
Forslag Analyse Impl og test Prodsetting Gevinst

25. Erfaringer fra innføring av
smidige praksiser

26. Eierskap til prosessen
Ildsjeler startet innføringen og
passet på prosessen.
Folk slutter - til tider hadde vi
ingen som tok spesielt ansvar

27. Eierskap til prosessen
Prosessen bør være forankret. Noen bør sørge
for at den følges.
Ildsjeler startet innføringen og
passet på prosessen.
Folk slutter - til tider hadde vi
ingen som tok spesielt ansvar

28. Product owner
Styringsgruppa er formelt
eier.
Prosjektleder / arkitekter
fungerer til tider som eier.

29. Product owner raskt. Uheldig med
Viktig å kunne ta avklaringer
“skybert” product owner.
Styringsgruppa er formelt
Ta avgjørelser på forskudd hvis du er trygg på
eier.
utfallet.
Prosjektleder / arkitekter
fungerer til tider som eier.

30. Teamsammensetning
Tverrfaglige team.
Flere team med forskjellig
fokus (mellomvare og
kanal)

31. Tverrfaglige team leverte veldig bra mtp
Teamsammensetning
funksjonalitet. Ulempen var at de forskjellige
systemene som avga ressurser mistet kontroll
Tverrfaglige team.
og styring.
Flere team med forskjellig
Ekstrem fokus på leveranse fører til dårligere
fokus (mellomvare og
kanal)
kodekvalitet. Motvirkende tiltak bør vurderes.

32. Estimering
Tradisjonell estmering
Planningpoker
Uforbredt
Enkelte forbreder presentasjon av
oppgaven.

33. Estimering
Planningpoker fungerte bra for oss. Hele teamet
er commitet til estimatet og deler kunnskap om
hva som skal gjøres.
Tradisjonell estmering
Planningpoker
Uforbredt
Enkelte forbreder presentasjon av
oppgaven.

34. Scope
Til å begynne med rørte vi
ikke scopet i sprinten ->
Endring == avbrudd.
Etter hvert begynte vi å
jonglere med sprinten.

35. Commitmentet til utviklerne kan forsvinne
Scope
dersom sprinten endres hyppig.
Kjør kortere sprinter hvis dere ikke klarer å holde
Til å begynne med rørte vi
sprinten stabil.
ikke scopet i sprinten ->
Endring == avbrudd.
Etter hvert begynte vi å
jonglere med sprinten.

36. Parprogramering
ad-hoc
Tvungen parprogramering
Rullering
Velge selv
Ved behov og som
substitutt for QA funket
best

37. Parprogramering
Parprogramering fungerte best når det var
komplekse problemstillinger, man hadde behov
ad-hoc
for opplæring eller som substitutt for QA.
Tvungen parprogramering
Rullering
Velge selv
Ved behov og som
substitutt for QA funket
best

38. Kalender tid og tilgjengelig
tid.
Alle oppgaver inn i sprinten
Estimere med lavere burn-rate.

39. Kalender tid og tilgjengelig
Sett av tid til arbeidsoppgaver som må gjøres
tid.siden av. Estimer f.eks med at folk klarer å
ved
jobbe 6 timer pr dag med prosjekt.
Alle oppgaver inn i sprinten
Estimere med lavere burn-rate.

40. Sprint demo
Mellomvaresystem
Ikke noe gui
Funksjonelle tester
Klienter med grensesnitt
Demo av funksjonalitet

41. Sprint mellomvaresystem fungerte dårlig.
Demo av demo
Demo av klienter fungerte ok, men diskusjonen
dreide seg fort om utseende og ikke funksjon.
Mellomvaresystem
Behovnoe gui
Ikke for styring av disse møtene.
Funksjonelle tester
Klienter med grensesnitt
Demo av funksjonalitet

42. Retrospectives
Kjørte retrospectives etter hver
sprint
Sjeldnere etterhvert
Til slutt kjørte vi ikke
retrospectives

43. Retrospectives som arena er viktig.
Retrospectives
Kjør dem hver gang. Hvis det ikke er noe å ta
opp kan man bare avslutte.
Kjørte retrospectives etter hver
sprint
Sjeldnere etterhvert
Til slutt kjørte vi ikke
retrospectives

44. Sprint frekvens
Sprinter rett etter hverandre
Pauser mellom sprinter.
Stabiliseringsprinter.

45. Sprint frekvens
Det er intenst å jobbe smidig.
Det kan rett etter hverandre
Sprinter være lurt å ha noen hvileskjær mellom
sprintene.
Pauser mellom sprinter.
Stabiliseringsprinter.

46. Oppskalering
Scrum of scrums
En fra hvert team møtes
med jevne mellomrom.
Look ahead
kort planlegging av
sprintene fremover.

47. Scrum of scrums fungerte ikke så bra for oss.
Oppskalering
Look a head for å kompansere for sjeldne
Scrum of scrums
releaser fungerte bra.
En fra hvert team møtes
med jevne mellomrom.
Andre tips: Samle alle i et stort rom for å
planlegge kan også virke.
Look ahead
kort planlegging av
sprintene fremover.

48. Kanban
Brukes av
vedlikeholdsteam.
Minimere tiden en
oppgave er i systemet
Lite work in progress

49. 2 2
Backlog In progress QA Done

50. 2 2
Backlog In progress QA Done

51. 2 2
Backlog In progress QA Done

52. Oppsummering.
Smidige metoder gir:
Målbart bedre produktivitet (for oss)
Bedre forretningsforståelse hos utviklere. IT er et
middel, ikke målet.
Økt leveranseevne
Større risiko for teknisk gjeld.
Økt synlighet og bedre kommunikasjon.

53. Oppsummering.
Smidige metoder krever:
Et dedikert team.
At smidige praksiser faktisk benyttes

54. Viktig å ikke glemme det vi
tar for gitt...
Kontinuerlig integrasjon
Testdrevet utvikling
Kodegjennomgang eller
parprogramering