I min kjellerbod er det veldig fullt rett til venstre rett innenfor døra, for det er så lett å løpe ned med noe jeg ikke trenger å ha stående fremme og lempe det der. Boden har reoler og to skap, men det er ofte jeg ikke tar meg tid til å finne den beste plassen for det jeg bærer ned.  Dette tar jeg ikke så  tungt, for jeg  finner stort sett det jeg leter etter senere. Men jeg har alltid intensjoner om å få ryddet ut av boden når borettslaget leier container.

For mange er innboksen en kjellerbod hvor man oppbevarer det som er kjekt å ha – gjerne rett innenfor dørterskelen uten å legge i mapper – og ettersom e-postene kommer til innboksen av seg selv fylles den enda raskere enn boden.

Hvis du bruker innboksen som arkiv fordi det er stedet med best struktur og best funksjonalitet for  søk og gjenfinning, så er det noe annet som er galt. Betyr det at det ikke finnes noen gode samhandlingsløsninger? Betyr det at du har en egen mappestruktur du ikke selv klarer å finne frem i? Betyr det at det er vanskelig å legge vedleggene som kommer med e-postene på rett plass.

E-post er så lett. Det er litt som kopimaskinene på 1990-tallet. Det ble så lett og billig å ta en kopi så man gjorde det for sikkerhetsskyld. Selv om mange arbeidsplasser har begrensing på størrelsen på innboksen, så er det ikke regler eller restriksjoner på hva man får lagre. Derfor tenker man at det er billig teknologi. Man hvis man spør den IKT-personen som har Exchange ansvar hva han eller hun synes, skulle han ønske at folk var litt flinkere til å slette e-post; særlig at folk kunne slutte å sende morsomme e-poster med store bilder som blir sendt til den ene kollegaen etter den andre og slik tar opp mye plass mens den vokser som celledeling. Akkurat som du ikke ønsker å måtte betale ekstra for å leie oppbevaringslokaler for esker du ikke husker helt hva inneholder, ønsker heller ikke IKT-avdelingen å betale for å ta vare på irrelevant informasjon.

Det finnes tekniske e-postarkiveringsløsninger for å avlaste Exchange servere og arbeidsplassen bør tilrettelegge med gode samhandlingsløsninger, men mye kan også gjøres med å forbedre egne rutiner.

Fem tips til høstdugnad i den digitale kjellerboden din:

1. Slett med en gang det som bare var til informasjon og som du aldri kommer til å få brukt for. Dette burde være selvsagt, men det er så lett å glemme.
2. Ha kontroll på mappestrukturen i innboksen. Sorter det du vil ta vare på over i mapper. Det er ikke lurt å ha for mange mapper, men prosessen å flytte e-post over i mappe gjør det bevisst på om du er interessert i å ta vare på den eller ikke.
3. Bruk lenker istedenfor vedlegg der det er mulig. De arbeidsplassene der man har gode samhandlingsløsninger er det bedre å dele lenker til dokumenter enn å sende dokumenter som vedlegg for å være sikker på at det er siste versjon man får se. Og privat er det like greit å sende lenker til digitale fotoalbum, som å sende bilde-filer som vedlegg.
4. Lagre de vedleggene som du kan få brukt for. E-post kan være en formidler av viktig informasjon. Hvis vi snakker e-post i jobb sammenheng, bør informasjonen overføres til et arkivsystem eller en informasjonshåndteringsløsning slik informasjonen blir virksomheten sin og ikke din.
5. Lag rutine av slettingen. Hvis du rydder e-posten sammen med morgenkaffen, før du går for dagen eller en gang i uken, blir det enklere å finne det du faktisk har brukt for

 Både du som enkeltperson og du som virksomhet har best av å ikke ha mye i innboksen!

Rutinepreget evaluering
Å evaluere seg selv er selvsagt viktig også i andre prosesser enn Scrum. Det å stadig forbedre seg, for å kunne jobbe mer effektivt, levere bedre kvalitet og trives bedre som team, er en nøkkelfaktor for suksess i de fleste prosjekter. Dessverre kan retrospektivmøter etterhvert bli rutinepregede; En aktivitet man gjør iterasjon etter iterasjon, uten egentlig å få fram de tingene som betyr noe, eller tenke nytt om temaer som går igjen gang etter gang. Da kan det ofte hjelpe å bryte opp mønstrene og gjøre noe nytt, for å skape variasjon og nytt engasjement rundt retrospektivet.

Her er et referat fra et retrospektiv jeg nylig hadde sammen med teamet jeg er Scrum Master på. Kanskje kan disse øvelsene inspirere deg til å skape ny glød neste gang du skal delta på et retrospektiv.

Første øvelse: Tidslinja
Først tegnet vi opp ei tidslinje som illustrerte de tre ukene som iterasjonen hadde vart. Det var ei rett linje med helgene og andre fridager markert. På denne linja tegnet vi inn viktige hendelser. For eksempel måtte vi i slutten av første uke endre løsningsbeskrivelsen på flere av oppgavene på iterasjonskøen, fordi de var basert på en forutsetning som viste seg å være feil. I uke to måtte vi gjøre noen uplanlagte feilrettinger på en tidligere leveranse, og i uke tre fikk vi et nytt medlem på teamet.

Dette er noen eksempler på ting som kan tegnes inn på tidslinja. Det er ingen regler for hva som er riktig eller feil å tegne inn. Stort og smått kan tas med. Poenget med denne øvelsen er rett og slett å friske opp hukommelsen til teamet. Vi hjelper hverandre med å huske hva vi skal evaluere.

Andre øvelse: Happygraf
Under tidslinja fikk så hvert teammedlem anledning til å tegne sin Happygraf. En Happygraf er en kurve som viser hvor fornøyd/glad eller misfornøyd vedkommende har vært i løpet av iterasjonen. Jo høyere kurve, jo mer fornøyd er du. Skalaen bestemmer dere selv. Dette er en morsom måte å uttrykke hvordan du har hatt det de siste tre ukene. Og det gir en fin innfallsvinkel til å kommunisere om følelser, uten å bruke ord.

Tredje øvelse: Stikkordslotto
I den siste øvelsen fikk hvert teammedlem utdelt grønne og røde lapper. På de grønne lappene skrev vi ting som hadde fungert godt i iterasjonen, ting vi ville fortsette med å gjøre. På de røde lappene skrev vi forbedringspunkter, ønsker om endring. Her brukte vi stikkordsform, slik at vi bare skrev et ord eller et uttrykk på hver lapp. Setninger var forbudt.

Deretter samlet vi inn alle lappene og blandet dem sammen. De grønne lappene i en haug, og de røde i en annen. Så trakk vi etter tur en og en lapp fra en bunke, og leste stikkordet på den høyt. (Fikk vi en av våre egne lapper la vi den tilbake og trakk en ny.) Den som trakk en lapp måtte prøve å tolke hva stikkordet betydde. Da kunne hun gjerne bruke sine egne erfaringer fra iterasjonen til å forklare hva vedkommende hadde ment, og hva hun selv ville legge i ordet.

Etter at hun hadde sagt hva hun tenkte stikkordet betydde, skulle den som hadde skrevet lappen forklare hva han egentlig hadde ment. På denne måten fikk vi minst to forskjellige vinklinger på samme tema, og svært ofte gode diskusjoner som følge av det. En av oss hadde samtidig rolle som sekretær, og førte et referat av hva som ble sagt.

Tiltak og ambisjoner
Sammen fikk disse tre øvelsene fram flere lærdommer fra de siste ukene. Vi diskuterte flere vinklinger enn vi tidligere har gjort på samme tema, og gravde dypere i noen enkeltsaker. Til sammen brukte vi ca to timer på øvelsene. Vi kombinerte det med lunch, og hadde kjøpt inn mat.

I begynnelsen av den påfølgende iterasjonen tok vi en gjennomgang av referatet fra retrospektivet. Vi valgte ut de tre viktigste punktene hvor vi ønsket å sette oss konkrete mål for forbedring. Vi ble enige om tiltak og ambisjoner for hvilke resultater vi ønsket å oppnå. Denne gjennomgangen brukte vi ca en time på.

Dine erfaringer
Hvilke erfaringer har du med retrospektiver? Har du opplevd noe som har fungert spesielt godt, eller har du tips til øvelser som er morsomme og gir gode resultater?

Nå skal det selvsagt sies at man helst bør følge de maler og bruke de rammeverk som arkitekten eller teamet sammen har tenkt at prosjektet skal bruke.  Sånn sett finnes det regler for hva som er rett og galt.  Men når det finnes slike maler og rammeverk, da stiller vi oss ikke dette spørsmålet. Det er når vi beveger oss utenfor de etablerte malene at spørsmålet gjerne dukker opp: Er dette riktig? Og det er litt trist når det skjer. For det er tegn på at vi ikke stoler på oss selv til å kunne komme med gode nok løsninger. Og det synes jeg vi skal gjøre. Det har vi all grunn til å gjøre, flinke som vi er

Vi bør absolutt fortsette med å stille spørsmål om hvorvidt koden vår kan forbedres. Men spørsmålet bør heller være “Hva synes du?” Vi bør fortsette med å involvere flest mulig. Men det bør gjøres som en diskusjon blant proffesjonelle utviklere der alle har gode poenger å komme med, og ingen sitter med fasiten. Det er da det er morro å jobbe som et team.

Programmering burde ikke bare oppleves som å fargelegge inni ferdig-opptegnede figurer. Det burde være litt frihånds-arbeide også. Det er når du føler at du er med på å skape løsningen at det er gøy å programmere. Og det er når man har det gøy at man jobber best og utvikler seg mest.

Det finnes en rekke innovasjonskonsulenter som gjerne hjelper til med den kreative fasen, eller the Fuzzy Front End (FFE). En kreativ seanse på 2 timer, 80 ideer på gule lapper, ett hav av muligheter – hva skjer så? Ofte veldig lite. Enten er ideene som kommer inn for lite markedsrettet (nye kleshengere i garderoben…), eller man klarer ikke å realisere potensialet i de ideene som faktisk er gode fordi prosjektet ikke blir dratt fremover eller ideene ikke blir valgt ut blant de 80 andre. Man ender opp med at alle ideene blir “liggende i skrivebordsskuffen”, kanskje sporadisk lest men ofte glemt. Isteden burde man valgt de fem beste og dratt de videre med sin beste prosjektleder. En studie omtalt og gjennomført på nytt på stammen.no viser sågar at det ikke er de kreative workshopene ideene kommer fra, men fra naturen!

Nå finnes det altså en rekke sosiale, gjerne nettbaserte verktøy for å gjøre samhandlingen bedre og mer rettet mot innovasjon. Mange av dere kjenner sikkert til åpne sider som myStarbucksIdea der alle kunder av Starbucks oppfordres til å komme med ideer. Mange firmaer, har kjørt flere interne konkurranser med lignende sider for å få frem ideer. Vi i Steria brukte i sommer Spigit som samhandlingsverktøy for å få inn ideer først, og deretter drive prosessene videre nettopp for å unngå at ideene blir liggende i en skuff, men sørge for at de blir kommentert, utredet, videreutviklet, besluttet gjennomført, forankret, testet ut på kunder og realisert.

Innovation management software er et område som har modnet kraftig de siste to-tre årene. Det finnes lister over løsninger her, her og her og finn.no har hatt sin finnOpp-løsning siden juni 2007.

Porteføljen av løsninger kalles gjerne innovation management eller idea management tools. Har din bedrift tatt i bruk slike løsninger?

Lean kommer fra en asiatisk kultur, der det kollektive og prosessen i seg selv er det sentrale. Lean er laget for å strømlinjeforme en spesiell måte å løse en kjent oppgave på. Agile på sin side kommer fra USA, der individet fremheves over alt annet (“Individuals and interactions over processes and tools”). Agile er først og fremst en effektiv måte å jobbe på når vi ikke kjenner veldig godt til omfanget og innholdet i oppgaven, og er nødt til å finne veien samtidig som vi går den.

I et foredrag på Scandinavian Agile Conference 2009 presenterte Jim Coplien disse 9 punktene der Lean og Agile er motstykker:

En gjennomgang av disse punktene kan være tema for et senere innlegg. Det jeg vil presentere denne gangen, er to praktiske øvelser som illustrerer noen av forskjellene og styrkene ved Lean og Agile. Øvelsene tar ca 5 minutter hver.

Øvelse 1: Agile

Finn en gruppe på ca 10-15 personer, og la de stå i et åpent område som de kan bevege seg rundt i. Hver person skal tenke på to andre personer i gruppa. Når alle har valgt ut sine to personer (uten å avsløre til noen hvem de har valgt), så er oppgaven som følger: Hver og en person skal nå plassere seg slik i rommet at han eller hun har nøyaktig like stor avstand til de to personene vedkommende tenkte på.

Før de får begynne å løse oppgaven, så er dette et morsomt spørsmål å stille til eventuelle prosjektledere i rommet: Hvis man skulle benytte klassisk prosjektledelse til å lede gruppa i denne øvelsen, hvordan skulle man gå frem da? Hvilke planer og retningslinjer kunne man lage som ville hjelpe dem fram til et raskt og godt resultat? De fleste vil snart komme fram til den konklusjonen at det er en ganske vanskelig (kompleks) oppgave.

Om vi benytter Scrum som eksempel på en smidig måte å løse dette på, hva ville en god Scrum master eller coach da si? Bare gjør det! Vi lar gruppa være selvorganiserende, og lar hvert enkelt individ ta ansvar for å på en selvstendig måte løse sin del av oppgaven, men i tett samarbeid med de andre i gruppa. Resultatet vil bli at etter en kort tid med tilsynelatende kaotiske og uorganiserte bevegelser, vil alle ha funnet likevektspunktene sine som til sammen løser oppgaven. Et resultat som ville være svært mye mer krevende å oppnå med en sentralt styrt prosess.

Øvelse 2: Lean

Hva så med Lean, hvordan kan det illustreres ved hjelp av en øvelse? Her trenger vi litt færre personer, ca 10 er fint. Gi en tilfeldig person i gruppa en gjenstand han kan holde i handa (ei tom flaske er et godt alternativ), og presenter dem for følgende utfordring: Gjenstanden skal nå sendes fra person til person i alfabetisk rekkefølge basert på fornavn. Det skal skje så raskt som mulig, og de vil bli tatt tiden på!

Ved første forsøk vil gruppa bruke litt tid på dette. De må fortelle navnene sine for å finne riktig rekkefølge. De vil typisk bruke et halvt til to minutter på å bestemme rekkefølgen og sende gjenstanden rundt. Fortell dem resultatet, og spør så om de kan gjøre det igjen, raskere. Det vil de naturlig nok klare, etter som de nå bedre kjenner navnene til hverandre.

Etter å ha fortalt dem tiden for forsøk nummer to, la dem forsøke en gang til, og be dem tenke på måten de står plassert på. De vil oppdage at det å stå på rekke eller i en sirkel, i alfabetisk rekkefølge, vil gjøre det enklest mulig å sende gjenstanden fra person til person. Vi eliminerer waste!

Hvor raskt er det mulig å klare det? Om de står i en tett sirkel, og hver enkelt så vidt berører gjenstanden før nestemann gjør det, kan de klare øvelsen på under et sekund. Det vil være en ganske dramatisk forbedring fra det første forsøket! Det viser hvor effektiv Lean kan være på denne typen oppgaver.

Oppsummering

Lean og Agile er laget for å løse forskjellige typer oppgaver. De kommer fra forskjellig bakgrunn, og selv om de virker like, så skiller de seg vidt fra hverandre på noen sentrale områder. Øvelsene over demonstrerer noen av de spesielle styrkene til de to prosessene. Disse styrkene er det viktig å huske på når man skal velge tilnærming til et prosjekt eller andre arbeidsoppgaver som krever en god prosess.

Hvilke erfaringer har du som leser gjort deg med Lean og Agile? Har du opplevd oppgaver eller prosjekter der de har passet spesielt godt eller spesielt dårlig?

Som en oppsummering på konferansen presenterer Kuppinger Cole de fem viktigste trendene innenfor IAm, GRC og Cloud computing. Nytt av året er at årets konferanse er slått sammen med Cloud Computing som virkelig er en het potet i Europa nå om dagen. Alle innlegg fram til nå har kommet inn på temaet, og det er stor spenning relatert til dette temaet som er upløyd mark. De viktigste trendene slik de blir formidlet er bl.a. en økende grad av justering mellom virksomhet og IT og evolusjonen mot et hybrid IT miljø bestående av et godt administrert miljø med en blanding av både interne og eksterne IT tjenester. Her er de heteste trendene , oversatt etter beste evne i tilfeller av manglende norske uttrykk, oppsummert fra konferansebrosjyren:

Identity and Access Management (IAM)

1. Mer fleksibilitet i arkitektur
   IAM-arkitektur er i endring. Den klassiske monolittiske tilnærmingen med provisioning som kjerne er kun en av flere arkitekturer som vurderes av integratører og kunder. Økende fleksibilitet i arkitekturer, samt integrasjon mot IT tjenester og virksomhetsportaler med sstøte for flere forsyningsverktøy blir mer og mer en realitet. Det hjelper også kunder med å implementere IAM raskere, biligere og mer spisset enn tidligere.
2. Tilgangsstyring og forsyning blir mer integrert
   Tilgangsstyring, også kalt IAM-GRC, er blitt en standard i flere arkitekturer og implementeringer, og er plassert på toppen av brukerforsyningen. Det er en økende grad av integrerte tilnærminger, samt en utvidelse av foryningsverktøy i form av tilgangsstyringsverktøy med mer støtte for integrasjon mot flere forsyningsverktøy i tillegg til adaptere for direkte tilkobling til mål- og fagsystemer. KuppingerCole forventer at denne trenden vil fortsette, og da med flere opsjoner for kundene og at tettere integrasjon mellom ulike teknologier vil bli mer standard.
3. Allsidige autentiseringsmekanismer blir mer modent
   Allsidige autentiseringsmekanismer, da i betydningen muligheter for å fleksibelt bruke ulike autentiseringsmekanismer basert på vanlig mellomvare blir mer modent og implementeres av flere leverandører. Dette muliggjør gjenbruk av sterk autentiseringsteknologi, samt mulighet for å velge den mest hensiktsemssige teknologien for ulike grupper av brukere (f.eks. interne og eksterne brukere) og brukstilfeller. Kostnaden med sterkere autentisering vil bli redusert.
4. Føderasjon finnes der ute
   Føderasjon, et tema som er gjenstand for mye diskusjon, er blitt en realitet. Tilsutningsraten er økende og vil fortsette å øke. I stedet for at man diskuterer potensialet blir nå føderasjon implementert i prosjekter med virkelige tilfeller.
5. Økende tilslutning av IAM i mellomstore bedrifter.
   IAM har fram til nå kun vært interessant for store selskaper og organisasjoner, og spesielt organisasjoner med compliance krav, men blir nå i økende grad relevant for mellomstore organisasjoner som middel mot å beskytte seg mot data- og informasjonslekkasjer og etterlevelse av krav angående personvern. Leverandører med standardimplementeringer og lettvekter produkter vil helt klart tjene på dette.

GRC – Governance, Risk Management, Compliance

1. Fra punktløsninger til GRC arkitektur
   Det er i dag for mange GRC initiativ i organisasjonene. Det spås at dette vil endre seg mot at flere virksomheter tenker mer på en helhetlig GRC arkitektur før man investerer i egne punktløsninger. Dette vil hjelpe virksomhetene til å optimalisere de investeringene som gjøres.
2. Tilgangsstyring som et startpunkt
   Tilgangsstyring er en av de mest økende områdene innenfor IT. Det betraktes som et logisk startpunkt for GRC initativ. Selv om det kun dekker en liten del av It-kontroller, er disse viktige, nemlig de som omhandler tilganger, informasjonslekkasjer, lovverkt angående personvern, og opphavsrett og/eller åndsverk. Det forventes at flere selskaper vil fokusere på tilgangsstyring når de skal investere i IT-GRC.
3. Lukke sløyfen for tilgangsstyring
   Et aspekt ved utviklingen er at det i økende grad blir mer integrasjon med automatiseringsteknologi for avstemming, som lukker sløyfen for endringer i målsystemer for attestering og sertifiseringer som har hatt fokus fram til nå. Disse tilnærmingene av lukking av sløyfene som støtter ikke bare reaktive men også prevantive kontroller blir mer og mer standard i markedet for tilgangsstyring (Access Governance).
4. Virksomhets-GRC åpner opp for IT-GRC
   I dag er mange av de såkalte virksomhets-GRC verktøy (bedre definert som virksomhetsorientert GRC ) hovedsaklig fokusert på forretningssidens syn på risiko, f.eks. drifts og noen ganger strategisk risiko. Men, forretning er basert på IT-systemer. Derfor er ITrisiko og driftsrisiko tett relatert, og de automatiserte kontrollene for driftsrisiko er basert på på informasjon i IT-systemene. Av den grunn må desse to verdenene konvergere, som helt klart er en stor trend i dag. Kuppinger Cole forventer at muligheten for å støtte integrasjon mellom virksomhetsstyring og IT-styring vil bli en nøkkedifferensiator mellom leverandører.
   
5. Risikokonsepter blir innført
   Risiko er i økende grad forstått som et nøkkelkonsept for IT-ledelse. Risikokonsepter blir i økende grad støttet av verktøy og implementert i organisasjonen. Men, det er typisk i dag et syn på organisatorisk og strategisk risiko som er splittet fra synet på IT-risiko. Analyseselskapet forventer at dette sakte men sikkert vil endres.

Cloud computing

1. Fra taktikk til strategi
   Cloud computing flytter seg nå fra taktikk til strategi – fra opportunistisk bruk av eksterne tjenester mot en strategisk tilnærming for anskaffelse av tjenester som dekker både interne og eksterne tjenester på en konsistent måte. Utviklingen er obligatorisk for muligheten til en fleksible anskaffelse av tjenester samt for å minimere risiko ved å ta i bruk standardiserte tilnærminger for valg av tjenestetilbyder(e).
2. Hybride IT-miljøer blir standard
   Virksomhetenes miljøer for cloud computing vil i økende grad være hhybride, med en blanding av eksterne og interne tjenestetilbydere. For de aller fleste organisasjoner vil dette bli en langsiktig realitet, og det er faktisk en realitet i dag når vi ser på eksterne tjenestetilbydere som blir benyttet på mange områder som bl.a. webkonferanse, webhotell, samt SaaS applikasjoner.
3. Fokus på tjenester og ikke på at de er eksterne
   Med utviklingen fra en taktisk tilnærmingen mot standardisering vil tjenester bli kjernen i cloud computing – alle typer av tjenester og ikke bare eksterne tjenester. Evnen til å vellykket administrere IT er veldig avhengig av en konsistent tilnærming for anskaffelse og administrasjon av tjenester, uavhengig av hvor de kjøres. Dette vil i større grad bli forstått med resulterende endring av fokus fra få store og populære tilbydere av cloud computing mot endring av IT-strategi og ledelse.
4. Det blir mer fokus på sikkerhet enn tidligere
   På nåværende tidspunkt blir sikkerhet sett på som et tema innenfor og for skyen, i hvert fall delvis. Kuppinger Cole forventer en økende grad av kunnskap om virkelige sikkerhets- og styringsspørsmål, som helt klart er forskjellig fra dagens tåkete sikkerhetsbekymringer. Utviklingen vil gi organisasjoner bedre muligheter til å håndtere cloud risiko og bygge gyldige sikkerhetsstrategier for bruk av eksterne tjenester i skyen.
5. Mange nyetableringer, sammenslåinger og oppkjøp av selskaper
   På lik linje som i andre nye markeder innenfor IT er det mange nyetableringer i markedet for cloud computing, og flere vil komme. Gitt at det er mange nye trusler er det nok av plass for oppstarter. På den andre siden vil det bli flere oppkjøp av større leverandører som vil utvide og styrke sitt eget cloud computing tilbud.

Verden ser altså ut til å ble mer hybrid enn hva vi ser er vanlig i dag. Interne og eksterne brukere, interne og eksterne applikasjoner og tjenester må administreres og styres. GRC skal dekke dette. IAM må virke med alt sammen. Bevegelse mot en tilnærminger som må støtte denne hybride IT-verden, samtidig med sterk justering mot forretningsnærhet, blir kjernepunkter ITsjefen må forholde seg til. Dette er også i samsvar med hva spesialistene og leverandørene mener og tror også. Min egen vurdering og oppfatning av denne overfloden av informasjon og inntrykk er at Norge på mange områder ligger langt bak mange av landene her i Europa. Men jeg tror også at på mange av disse områdene kommer vi etter etterhvert som kundemarkedet modnes. We are all individuals… really? Det viser seg at vi ikke er så veldig spesielle med spesielle behov likevel hjemme på berget. Vi er derimot på mange områder hengende etter og har mer taktisk enn strategisk fokus.

Det smidige manifestet ble skapt av en gruppe svært talentfulle mennesker. Men alle sammen kom fra leverandørsiden av utviklingsprosjekter, noe som er tydelig allerede i den tredje av de fire verdiene:

Samarbeid med kunden framfor kontraktsforhandlinger

- som implisitt sier at “vi” ikke er kunden.

For å få ut de største gevinstene av smidige filosofier, må kundesiden også jobbe på en smidig måte. Dette betyr mer enn å skaffe en Produkteier som utviklerteamene kan jobbe med eller for. Kundesiden av prosjektet må jobbe ikke bare med utviklerne, men også med sin egen organisasjon og andre interessenter. Spesielt viktig er det at kundesiden av prosjektet må finne ut hvilke mål produktet må nå for å skape virkelig verdi for interessentene.

Så derfor lurer jeg på: Hvordan ville det smidige manifestet ha sett ut hvis det hadde blitt skapt av kunder i stedet for leverandører?

Her er resultatet av mitt lille tankeeksperiment.

Smidige verdier

Vi oppdager stadig bedre måter å utvikle systemer på, både ved å gjøre det selv og ved å hjelpe andre. Derved har vi lært oss å verdsette:

• Individer og samspill framfor prosesser og verktøy
• Fungerende system framfor utførlig dokumentasjon
• Å levere verdi til interessenter framfor å fullføre funksjonalitet
• Samarbeid med leverandør og egen organisasjon framfor kontraktsforhandlinger
• Å reagere på endringer framfor å følge en plan

Smidige prinsipper

(Merk: Nedenfor har jeg inkludert de original prinsippene, men uthevet de nye forslagene, slik at du enkelt kan se likhetene og forskjellene. Den norske oversettelsen av originalprinsippene er forøvrig basert på en diskusjon på smidig.no-forum.)

Vi følger disse prinsippene:

• (NY)
  Det hjelper ikke å gjøre tingene riktig hvis vi ikke gjør de riktige tingene. Vi må jobbe kontinuerlig med organisasjonen vår og med sluttbrukerne for å finne ut hva som er de riktige tingene.
• Vår høyeste prioritet er å tilfredsstille kunden gjennom å levere et verdifullt, kjørende system tidlig og hyppig.
  Vår høyeste prioritet er å skape verdi for interessentene gjennom tidlige og hyppige leveranser av programvare.
• Ønsk endringer i krav velkommen, også sent i utviklingen. Smidige prosesser utnytter endringer til å gi kunden konkurransefortrinn.
  Ønsk endringer i krav velkommen, også sent i prosjektet. Smidige prosesser utnytter endringer til å gi organisasjonen vår konkurransefortrinn.
• Lever fungerende programvare hyppig, fra et par uker til et par måneder, med preferanse for den korte enden av skalaen.
  Lever verdifulle løsninger hyppig, fra et par uker til et par måneder, med preferanse for den korte enden av skalaen.
• Forretningssiden og utviklere må jobbe sammen daglig gjennom hele prosjektet.
  Jobb sammen med interessentene og utviklerne kontinuerlig gjennom hele prosjektet.
• Bygg prosjektene rundt motiverte individer. Gi dem det miljøet og den støtten de trenger, og stol på at de får jobben gjort.
  Bygg prosjektene rundt motiverte individer. Gi dem det miljøet og den støtten de trenger, og stol på at de får jobben gjort.
• Den mest effektive metoden for å formidle informasjon til og innen et utviklingsteam, er å snakke ansikt-til-ansikt.
  Den mest effektive kommunikasjonsformen er å snakke ansikt til ansikt mens dere visualiserer samtaleemnet på papir eller tavle. Bruk andre former kun når tilleggsverdien er større enn tilleggskostnaden.
• Kjørende system er det primære målet på framdrift.
  Verdi realisert av interessentene er det primære målet på framdrift.
• Smidige prosesser fremmer bærekraftig utvikling. Sponsorene, utviklerne og brukerne bør kunne opprettholde et konstant tempo i ubegrenset tid.
  Smidige prosesser fremmer bærekraftig utvikling. Interessentene og utviklerne bør kunne opprettholde et konstant tempo i ubegrenset tid.
• Kontinuerlig fokus på teknisk kvalitet og godt design fremmer smidighet.
  Kontinuerlig fokus på høy teknisk kvalitet fremmer smidighet.
• Enkelhet – kunsten å maksimere mengden arbeid som ikke gjøres – er essensielt.
  Enkelhet – kunsten å maksimere mengden arbeid som ikke gjøres – er essensielt.
• De beste arkitekturene, kravene og designene vokser fram fra selv-organiserende team.
  De beste løsningene oppstår i selv-organiserende teams med klare mål.
• Med jevne mellomrom reflekterer teamet over hvordan det kan bli mer effektivt, og justerer arbeidsmåten sin tilsvarende.
  Med jevne mellomrom reflekterer alle involverte over hvordan de kan bli mer effektive, og justerer arbeidsmåten sin tilsvarende.

Oppsummerende ord

Jeg har holdt meg tett opp til de originale verdiene og prinsippene – kanskje for tett. Å ligge opptil originalen kan ha verdi – på en måte gir det kunde- og leverandørsiden en tydelig felles plattform. Dessverre det kan også bety at jeg overser noe viktig. Men det er ikke meningen her å skrive et helt nytt manifest (hvordan skulle jeg kunne det?), men heller leke rundt med “hva om…” og kanskje få fram noe verdifullt om likhetene og forskjellene mellom utvikleres og kunders perspektiv.

Hva synes du?

(takk til Johannes, Eli og Simen for innsikter og forslag som gjorde denne artikkelen bedre)

Hvem?

Det viktigste når du skriver en blogpost er å være bevist på hvem dine lesere er. For denne artikkelen gjorde jeg meg følgende tanker:

• Hva er leserens forhold til tema? Jeg regner med at du som leser blogger litt eller tenker på å starte å blogge.
• Hva tenker leseren om tema? Jeg regner med at du synes det er vanskelig å komme i gang med bloggingen.
• Hva får de ut av å lese blogposten? Etter å ha lest posten vil jeg at du skal føle deg mer i stand til å skrive dine egne blogposter.

Hva?

Når du vet hvem du henvender deg til, er det viktigste å jobbe med innholdet og strukturen.

• Struktur: For hvert avsnitt vil du miste 5% av leserne (for å trekke et tall ut av lufta). Skriv det viktigste først
• Språk: Bruk aktivt språk som henvender seg direkte til leseren. Et eksempel på aktivt språk er: “Bruk aktivt språk som henvender seg direkte til leseren”
• Eksempler: Det er vanskelig å formidle abstrakte ideer. Eksempler er enklere.

Hvordan?

Når jeg starter med en blogpost, starter jeg nesten alltid med å kladde på papir. Jeg skriver strukturen ned, river i stykker papiret og skriver den ned på nytt. For meg fungerer det veldig godt å skrive på papir for å bearbeide tankene. Når jeg tar fram datamaskinen, blir jeg distrahert av verktøyene.

Mine mest populære artikler er de som der jeg har fått mye innspill av andre før jeg har publisert artiklene. Send utkast til artikkelen til folk du stoler på og be om konstruktiv tilbakemelding. Konstruktiv tilbakemelding er konkret og spesifikk: For eksempel: “Dersom blogposten hadde brukt punktlister også i siste avsnitt hadde den virket mer helhetlig uttenkt”. Personlig liker jeg best å dele utkastene mine med andre via Google Docs, framfor å maile vedlegg frem og tilbake.

Spre ordet via de kanalene du kommuniserer med: Pass på at bloggen har en RSS-feed. Bruk twitter, yammer, facebook, linkedin etc for å spre ordet. Ikke glem den gamle traveren email, heller (men for guds skyld, ikke spam folk!)

Hvorfor?

Som mennesker ligger trangen til å kommunisere i vårt DNA. Når jeg er entusiastisk om noe, føles det riktig å dele det. Å nå andre bekrefter vår egen eksistens.

Blogito, ergo sum!

I en ny undersøkelse som ble presentert i en pressemelding 26.1 går det fram at hver tredje norske virksomhet vil bruke sosiale meder i aktivt innen to år. I en tilsvarende undersøkelse før sommeren 2009 svarte 6 prosent av de norske it-sjefene at sosiale medier brukes som strategisk virkemiddel i deres bedrift. I høstens undersøkelse har andelen steget til 10 prosent. Dette viser at det er en endring i innstillingen, og det er stor grunn til å anta at reelt vil flere enn én av tre virksomheter faktisk bruke teknologier eller ideer fra sosiale medier aktivt innen 2012. Jeg mener at for de veien dit vil i de fleste tilfeller gå utenom de høyt profilerte tjenestene Twitter og Facebook.

Facebook og Twitter har åpnet for mange mye muligheter for markedsføring, kundekontakt og kommunikasjon (selv om Norsk Møteforum kom fram til noe annet i sin undersøkelse). Facebook blir av de fleste brukere ansett som en privat arena, mens Twitter fortsatt ikke har blitt så mye mer enn et nisjested for spesielt interesserte (ref nye tall). Jeg vil derfor påstå at i den profesjonelle verden er Facebook og Twitter av liten betydning utenfor marked- og kommunikasjonsavedlingene. For de andre delene av organisasjonene ligger gevinstene helt andre steder.

Folk flest har lært seg bruken av Facebook og ideene til web 2.0. La oss nå ta disse kunnskapene inn i bedriftene og utnytte dem i vårt daglige arbeid som for eksempel i produksjonsprosessen, i kunnskapsforvaltningen eller i prosessforbedringene.  Heldigvis er trendene allerede på vei inn i næringslivet, og det finnes mange gode eksempler som kan være til inspirasjon.

På T-banens nye driftsentral har de byttet ut gule lapper med mikroblogging. Foto: T-banen

Markedsplassen Finn er ett eksempel som har hentet inspirasjon fra sosiale nettsteder til sitt egenutviklede system ”FinnOpp”, som skal stimulere til ideskaping hos selskapets egne ansatte. Et annet eksempel er T-banen som bruker blogg som hjelpemiddel i overvåkning av trafikken. Flere kommuner har tatt i bruk sosiale nettsteder hvor brukerne kan melde om feil i nærområdet sitt. Her i Steria bruker vi Yammer, blogg, wiki og SharePoint aktivt innenfor kunnskapsdeling, erfaringsutveksling og i prosjektarbeid. Dette er gode eksempler hvor virksomhetene har tatt tak i enkelte viktige områder, og forbedret disse ved hjelp av sosiale medier.

Når det gjelder teknologi så skjer det også mye om dagen. Med SharePoint 2010 som lanseres senere i år tar Microsoft et steg videre inn i web 2.0 verdenen. I denne versjonen har elementer som grupper, mikroblogging, tagging, scoring, og forbedret søk blitt tatt inn som en del av løsningen. Dette er en trend som også gjenspeiles i løsningene til andre store aktører også som Lotus Connections fra IBM og Documentum fra EMC. I tillegg finnes det etter hvert at hav av mindre leverandører som leverer nisjeprodukter, som f.eks mikrobloggingstjenesten Socialcast, innovasjonshåndtering fra Induct og wikiløsningen Confluence.

Ettersom produktene blir mer modne, kunnskapen bedre og erfaringene flere er det stor grunn til å både tro og håpe at sosiale medier vil spille en aktiv rolle for langt flere enn én av tre bedrifter i 2012!

Det er lenge siden våren 2008 da Steria tok de første skrittene når det gjaldt bruk av sosiale medier. Første fase var utprøving av den nye teknologien. Internt testet vi ut bedriftswiki. Eksternt begynte vi å følge mer bevisst med på hva som skjer der ute på nettet, og spesielt på sosiale nettsteder. Ordinær presse hadde vi selvfølgelig overvåket lenge.

Neste skritt var å bli aktiv på Twitter og LinkedIn. Det ble opprettet Twitter kontoer som for eksempel STERIAlynkurs. Internt begynte vi å teste ut mikroblogging med Yammer. Yammer har i dag har utviklet seg til å bli et nyttig verktøy for mange Sterianere som kompletterer allerede eksiterende verktøy som internwikien og SharePoint-portal. Mer om Yammer kan dere lese om i et innlegg på samhandlingsbloggen.

Som en kompetansebedrift har kunnskapsdeling alltid vært viktig for Steria. Med Sterk blanding får de ansatte i Steria en ny kanal som er enkelt tilgjengelig for alle. Den går rett til kjernen på hovedprinsippene for sosiale medier, nemlig deling, respons og brukergenerert innhold. Sterk blanding skal være en arena hvor Sterianere kan dele med hverandre og med resten av verden. Det blir spennende å følge med på hva som skjer!