1) Støtte fra sjefen
2) En som brenner for gjennomføringen og tar initiativ
3) Et utviklermiljø der det å lære nye ting er viktig

Har man disse ingrediensene tror jeg man er i boks :)

Vi gjennomførte tilsvarende SKB en stund, noe som var veldig ok! Tror alle var med å deltok. Men en vi forsto jo en del ting måtte på plass:
1) Tema kunne folk velge selv, så lenge de syntes det var noe de kunne lære vekk. Alt fra utviklingsteknikker til hvordan bruke tankekart i arbeidet og en wrap-up av “7 habits of highly productive people”
2) Deltakelse ble premiert. Først med en flaske vin til hver “talker”, deretter en flaske vin til beste innlegg stemt fram av andre. Dernest etter en “hall of fame” liste ift. antall innlegg.
3) Gode diskusjoner kunne erstatte ziptalksene. Kommer mye bra ut av produktive samtaler, og av til hjelper det å reflektere i grupper.

I PA hvor jeg er nå er konsulentene utrolig mye spredd ut på en mengde forskjellige oppdrag. Utfordringen å lære fra hverandre er enda større enn utviklingsmiljøer. Konsulentene har derfor tatt eget initiativ til at alle som er “inhouse” eller har anledning til å være med samles annenhver fredag for en roundtable setting, hvor hver går gjennom sine prosjekter eller erfaringer og deler med andre. Jeg har vel aldri opplevd en større vilje til å motta konstruktiv kritikk og forbedringsvilje enn fra den gjengen med management consultants. INGEN setter seg på en høy hest i redsel for å få forbedringsforslag, og angsten for å rette kritikk er dermed fraværende fra resten ettersom man er trygg på at den blir tatt på en god måte. En befrielse!

Jeg anbefaler at:
1) Alle er delaktig i formen på ziptalks eller læringsfora. Hvis alle har mulighet til å påvirke øker også motivasjonen til å få det til å fungere.
2) Målet med samlingene er tydeliggjort. Hvis dere har et målkort eller evalueringsform på ansatte kan kunnskap/ erfaringsdeling inngå i dette.
3) Hvis du greier å synliggjøre en direkte gevinst fra en ziptalk stiger motivasjonen ytterligere. Hvis #1 f.eks, snakker om sin bruk av simple objects eller noen refactoring prinsipper, og #2 plukker dette opp og viser at vedkommende har brukt det dagen etter stiger motivasjonen ytterligere. Sånn sett kan premiering av oppfølging av gode ziptalks være vel så viktig som selve ziptalken.

Skal nye initiativer få rot til å feste seg er quick-wins et nyttig hjelpemiddel.

Lykke til, spennende å høre fortsettelsen. Høres ut som du har mange gode tiltak gående :)

Presentasjonene varer 30-60 minutter, og alle i teamet roterer på jobben med å lage presentasjon, med enkelte unntak her og der.

Jeg legger opp et løst program på halvårsbasis, hvor jeg foreslår interessante tema for hver person, basert litt på hva jeg vet de er interessert i eller jobber med, og så kan hvermann bytte ut sitt tema med noe annet om de ønsker.

Temaene veksler 50/50 mellom ting som er nytt og hipt i Java-verdenen, og resten går på domenekunnskap rundt de forskjellige komponentene i produktet vårt.

Tidligere hadde vi alltid møtet på onsdags ettermiddag, men ettersom dette kolliderte ofte med stress rundt deployment, bytta vi nylig til å ha det rett etter fredags-standup’en (vi har standup mandag og fredag), så fredags-standupen er nå litt mer romslig for diskusjon, og så setter vi i gang med foredraget etterpå.

Jeg føler det er ganske populært. Jeg tror et par faktorer hjelper til på suksessen:

* Det er obligatorisk deltagelse (sjefen støtter opplegget)
* En person (meg) har ansvaret for å organisere det
* Folk flest i teamet er ganske ydmyke i forhold til sitt eget kunnskapsnivå.

Jeg forsøkte nylig å innføre et tilleggsprogram kalt “Java Movie Hour”, hvor vi bestillte pizza på torsdagskvelden (kl 17) og så på en video fra JavaZone, etc. Det var frivillig oppmøte og de fleste møtte opp. Uheldigvis har vi ikke fått budsjett for mer pizza ennå :)

Situasjonen du befinner deg i er nok svært representativ for norske utviklingsavdelinger. Tradisjonelt er det en utbredt oppfattelse at man skal kunne alt man trenger når man begynner i jobben, selv om man kanskje kommer rett fra skolebenken, og ikke har filla peiling på hva det vil si å være en profisjonell utvikler. Det kreves mot å innrømme at man ikke kan alt, selv overfor seg selv. Å forsøke å lære nye ting er en rissiko – “hva om jeg ikke får det til?”. Da synes enkelte det er bedre å dra nisseluen ned over øynene og gjøre ting slik de alltid har blitt gjort.

Tenk gjennom om du virkelig er interresert i å ha med deg absolutt alle på den type læring og felles inspirasjon som vi snakker om her – det er ikke alltid det er verdt det å inkludere dem som ikke trekker i riktig retning. Kanskje du kan danne en lite kjerne som over tid kan vokse seg større. Til slutt vil den ensomme ulven så hvor mye bedre dere som utvikler dere har det – og bli med på leken – eller bli forbigått.

Utviklingssjefen innførte dette hos oss for halvanna år siden. Jeg var helt i hundre over tiltaket, men så snart at det ikke fungerte over hodet. Det var mange årsaker til det, bl.a.
1. Sjefen hadde ikke interesse av å følge det opp
2. Flere av utviklerne hadde ikke interesse av å bidra
3. Flere av utviklerne hadde ikke interesse av å være til stede i det hele tatt
4. Enkelte av utviklerne har en holdning om at de har vært i bransjen så mange år, at en ikke må prøve å komme og fortelle dem noe nytt….

Å ha en liten halvtime satt av til å helt løsrevet snakke og tenke fag burde være en selvsagt investering i de fleste kunnskapsbedrifter egentlig.