Hvordan få til endring – del 2

For noen år siden skulle vi endre måten vi jobbet på i en avdelning i et stort IT-selskap hvor jeg jobbet. Vi var allerede ganske smidige, og mye var riktig, men vi hadde likevel en vei å gå for å nå målet vårt med å kunne release software hver dag.

  • vi hadde en syklus på ca 6-9 mnd
  • vi hadde mange tester, men mye ble også testet manuelt
  • en del av testene som kjørte automatisk feilet – tilsynelatende tilfeldig
  • vi hadde mange kjente bugs
  • det var til tider dårlig kommunikasjon mellom medlemmer av teamet – selv om de alle jobbet i samme kodebase.

Det var altså mye å ta tak i – og vi så raskt at vi kunne ikke ta alt samtidig.

Som prosjektleder var jeg fristet til å si TA DERE SAMMEN! Vi må bedre kodekvaliteten, folkens! Jeg kunne til og med laget vakre slides. Men både jeg og resten av ledergruppen var sikre på at det ikke ville være til hjelp. Vi hadde lært om Mary Poppendieck sitt system 1 og system 2, så vi visste at vi måtte gå en annen vei.

Noen år senere kom jeg over en bok av Chip og Dan Heath. Den illustrerte Marys system 1 og system 2 svært godt ved å forestille seg en elefant (system 1) og en rytter (system 2) som skal styre elefanten. I tillegg presenterer boken tre overraskelser når det kommer til endring. Jeg har tidligere postet ett innlegg om denne boken, hvor jeg avslører første overraskelse (https://blog.iterate.no/2016/01/16/hvordan-fa-til-endring-del-1/). I dette innlegget vil jeg presentere de to siste overraskelsene – og forklare hva vi gjorde i situasjonen beskrevet innledningsvis.

Continue reading

Hvordan få til endring – del 1

En lørdag i 2000 i Chicago fikk kinogjengere utdelt store bokser med gratis popcorn før de skulle inn  og se filmen Payback. De fleste mottok gledelig de enorme boksene med popcorn, og gikk med på å ta med seg bøttene ut og levere dem tilbake etter filmen. Det de ikke visste var at de var deltakere i et eksperiment.

Denne teksten handler om endringsledelse, og en av utfordringene med å få gjennomført en endring hos seg selv eller hos andre. Skal man endre ens egne vaner, få til endringer i en organisasjon eller i et samfunn, er det mye det samme det handler om; klarer du å få folk til å oppføre seg på en annen måte enn det de gjør i dag? Suksessfull endring følger et mønster, og skal du få til en endring kreves det at du gjør tre ting samtidig.

Tilbake til kinogjengerne i Chicago. Popcornet de fikk utdelt gratis var av billigste type. I tillegg var det seigt og flere dager gammelt. Det var forskjellige størrelser på posjonene, men alle var så store at det skulle være umulig å spise opp popcornet man fikk utdelt. Eksperimentet ble gjennomført av Brian Wansink ved Cornell University, og gikk rett og slett ut på følgende; ville de som fikk de største porsjonene spise mer? Så alle bøttene med popcorn ble veiet før og etter kinofilmen.

Resultatet stemte med hypotesen til Brian, men var likevel overraskende tydelig; de med de største porsjonene spiste 53% mer enn personer med mindre porsjoner!

Her er det viktig å huske på at det var snakk om dårlig og gammelt popcorn, alle porsjonene var gigantiske, og popcornet var gratis. Det skulle ikke være noen grunner til å trykke i seg så mye popcorn som mulig. Undersøkelsen ble gjennomført flere ganger, ulike steder og med ulike filmer. Resultatet var alltid det samme:

Continue reading

Colic-driven Development

The idea behind the Oslo Opera House came after a role switch. When first opened eight years ago, visitors were presented with a fairy tale, allowing everybody to literally walk on top of the glacier-like surface of the building before being lured inside, into an adventurous quest for the “Hall of the Mountain King” (According to Norwegian folklore, The Mountain King normaly resides inside the Dovrefjell mountain range, who’s highest peak – Snøhetta – incidentally has the same name as the architect company that drew the Opera House). It was an iconic building that soon became a part of the identity of Oslo, and the web site still melts down twice a year, when next season’s tickets are out.

It’s a glacier. You’re supposed to walk on top of it

So how did they come up with this idea?

Continue reading

Developers, start thinking about design!

by Alexandra Leisse | alexandra@iterate.no | @troubalex

This is a written and slightly tidied version of the lightning talk I gave at this year’s Javazone.

We designers have long been told that we should learn how to program in order to really understand the medium we’re working in, and to develop a common language with developers. While I believe this to be true, I also believe that it should go both ways.

I regularly encounter a number of misconceptions about how to work as a designer. Let’s get those out of the way first:

Continue reading

Konsulenteriet må dø!

av Erik Assum / erik@iterate.no / @slipset

Dette er en transkribering av min lyntale på JavaZone i år. Det er ikke ordrett, men innholdet er relativt likt.

Introduksjon

Jeg kommer i denne blog-posten til å snakke om konsulenter, prosjekter og forvaltning, så jeg må begynne med å definere i alle fall disse begrepene. Deretter skal jeg si noe om hvordan jeg mener man bør bruke konsulenter. Dette holder jeg opp mot noen vedtatte sannheter jeg mener finnes om IT, og tilslutt en oppsummering.

Definisjoner

Wikipedia definerer en konsulent som

en tjenesteyter som i en profesjonell ramme tilbyr sin ekspertise innenfor et visst fagfelt, vanligvis i et begrenset tidsrom

I dag finnes ordet konsulent også brukt om innleid ekstrahjelp uten den kompetansen vi tradisjonelt forbinder med begrepet

Samme nettsted definerer et prosjekt som

En innsats som gjøres for å oppnå et definert mål, som oftest innenfor en planlagt tids- og ressursramme

Selv definerer jeg forvaltning som

Et sted der systemer laget i prosjekter bemannet med konsulenter blir sendt for å dø

Konsulentbruk

Så hvis jeg mener at konsulenteriet må dø, mener jeg da at all konsulentbruk er ufornuftig? Det enkle svaret er nei. Det litt utfyllende svaret er at man skal bruke konsulenter når man har korte og avgrensede oppgaver utenfor kjerneområdet. Eksempler på dette er f.eks om du skal bytte fra websphere til tomcat, flytte fra svn til git eller sanere noe gammelt ræl som ingen bruker lenger. Det viktige her er at det er konsulenten som er domene-eksperten. Ikke kunden.

En annen god grunn til å bruke konsulenter er fordi du mangler kompetanse og trenger hjelp til å komme igang. Eksempler på dette vil være å få opp et CI/CD-miljø eller begynne med et nytt programmeringsspråk som Clojure. Igjen er det konsulenten som er domene-eksperten og kundens mål vil være å nytte godt av denne ekspertisen for å unngå fallgruver og komme seg fortere igang.

Konsulenteriet må dø!

Så hvilken bruk av konsulenter er det som er så feilaktig at jeg mener at det må dø? Det er når man bruker konsulenter til oppgaver som ligger i de fast ansattes domene. Fordi da er ikke lenger konsulenter ekspertene. De er vikarer.

Grunnen til at jeg bryr meg om dette er at jeg mener at en slik bruk av konsulenter koster langt mer enn det smaker. For konsulentbruk er et optimaliseringsproblem, som så mye annet. Og for slike problemer må man kjenne både gevinster og kostnader. Dessverre er det også slik at en del av de gevinstene man ser for seg kommer man aldri til å ta ut. Det blir som å kjøpe opsjoner uten å utøve dem. Og det er jo bare dyrt.

Vedtatte sannheter om IT

De skulte kostnadene ved bruk av konsulenter, sånn rent bortsett fra at de som regel er dyrere enn faste ansatte forblir skjulte fordi kunden tror på følgende sannheter om IT.

IT er kun en utgiftspost

Fordi IT kun er en utgiftspost er det fint å kunne skalere ned i dårlige tider. Av samme grunn er det fint å kunne bytte ut dyre konsulenter med billigere vikarer som er like bra. Poenget her er at det er ytterst få bedrifter som klarer seg uten IT. Man må innse at for å lykkes idag, må IT integreres på alle nivåer i forretningen. IT må være forretningen , forretningen må være IT.

Domenekunnskap er uviktig

For at IT og forretning skal kunne jobbe sammen og komme med de beste løsningene på de vanskeligste problemene, må IT forstå forretningen bedre enn forretningen selv. Da nytter det ikke med vikarer som løper ut døra så fort prosjektet er overlevert til forvaltning.

IT systemer blir ferdige

At Politiet fortsatt bruker Straffesaksystemet som ble levert i 1979 er bare trist. Det som hadde vært kult var om politets Straffesaksystem hadde vært topp moderne og i kontinuerlig utvkling siden 1979.

Fordi vi anser systemer som levert, og ikke foredler dem over tid, blir de tilslutt helt ubrukelige og må byttes helt ut, ikke ulikt Svinesundsbroen. Men fordi man ikke har hatt noen kontinuerlig utvikling, har man ingen utviklere og man må inn med konsulentene, som må lære seg domenet som de ikke kan noe om. Og fordi man nå endelig skal få et nytt system, må man passe på at man får med seg alt man har savnet de siste 30 år, pluss litt til. Og når systemet blir definert som ferdig, enten fordi budsjettet er brukt opp, eller tidsfristen overskredet, forsvinner konsulentene med tilhørende domenekunskap ut i nye oppdrag i nye domener, og tilbake sitter brukerne med et system som ikke virker, hverken idag eller i framtiden.

Tilslutt

IT har kommet for å bli

Det er veldig få bedrifter eller etater idag som sier at, nei, IT er
ikke noe vi satser på. Manuelle rutiner holder lenge for oss. Idag må alle
IT systemer være under kontinuerlig utvikling, bortsett kanskje fra de
som ingen bruker.

Konsulent eller vikar?

Så hvis du er konsulent idag, bør du tenke deg om. Hvis du sitter ute
i oppdrag og egentlig bare er en midlertidig ansatt fordi kunden
ikke klarer å ansette folk, bør du kanskje heller hjelpe kunden ved å
forklare på en pen måte hvorfor de ikke er attraktive. For din rolle
som konsulent bør være ekspertrollen. Den som kan noe som kunden ikke
kan.

Men dersom du sitter ute i et tidsbestemt oppdrag og hjelper kunden
med å bli bedre på ting den ikke kan, eller løser et problem som
ligger på siden av kjerneområdet, så synes jeg du skal klappe deg selv
på skulderen og gratulere deg selv med å ha funnet et godt
konsulentoppdrag.

Experiences from ReactEurope

At the beginning of July, Truls and I went on our first work trip abroad to attend the first ever ReactEurope conference in Paris. A two-day conference dedicated to the very popular React.js, a frontend library made by Facebook, and other related topics. Despite of an intense heatwave in southern Europe and the lack of an A/C that could cool down 700 people in a single venue, we still feel that the conference was a great experience. There were many great speakers who presented interesting topics and we learned a lot from their talks. The speakers include the creators of React.js, React Native, Flux, ImmutableJS, GraphQL, Relay, Babel, Redux and React Router, all important parts of the React ecosystem. We also had many enlightening discussions with other attendees.

A lot of people in a not-so-big and no-A/C venue.

Continue reading

Lean summer of 2015 – Week 6

Can 6 tech students help a telecom giant innovate in 6 weeks? Telenor Norway wants to solve real problems for real people. As summer interns in Iterate – the lean startup consultancy in Norway – we’ve been hired to build, measure and learn how to unleash the power of future telco technology. Every week we blog about what we’ve learned.

Here’s week 6.

Our Lean summer has come to an end.

Six weeks ago we were given a task; to help Telenor innovate in different areas. With the rise in popularity and functionality of webRTC, Telenor wanted to know whether or not this technology could help.

first_day

Six nervous students preparing for their first day

We didn’t expect this project to be easy, and didn’t expect it to go without issues or problems. We expected guidance, but we also hoped for some freedom to try and fail for ourselves. Mistakes are a great opportunity to learn, but only if we can make and solve them on our own..

IMG_0120

Six great friends enjoying a last party together before going their separate ways

Continue reading