Enkelte predikerer Scrum som den eneste riktige måten å kjøre smidige utviklingsprosjekter på. Kjører man Scrum ”etter boka” betyr dette blant annet at:

• alle aktiviteter skal gjennomføres innenfor samme arbeidsblokk (sprint);
• alle på teamet skal være kryssfunksjonelle, og således kunne utføre hverandres arbeidsoppgaver;
• teamet optimalt skal bestå av 5-7 deltakere; og
• teamets medlemmer skal være 100% involvert i prosjektet.

Hva da når prosjektet er web-basert, og utviklingsteamet består av totalt 10-15 personer som inkluderer både utviklere, webskribenter, interaksjonsdesignere og designere?

Min erfaring er at prinsippene bak Scrum er forholdsvis enkle å sette seg inn i. Å  gjennomføre et smidig prosjekt i praksis er mye vanskeligere. Egne erfaringer er den beste veien å gå for finne ut hva som passer i din organisasjon eller prosjekt.

Her er 10 selverfarte tips som kan hjelpe deg på veien.

1. Sørg for at interaksjonsdesign ligger én sprint foran utviklerne

I et web-basert utviklingsprosjekt vil det være vanskelig å gjennomføre alle aktiviteter innenfor samme sprint (iterasjon). Dette skyldes at enkelte aktiviteter avhenger av hverandre. Grunnleggende wireframes og overordnet design bør være klart før utviklerne starter teknisk implementering. Før interaksjonsdesigneren starter arbeidet med innledende skisser, bør forretningssiden ha klare formeninger om hvilke bruksoppgaver og forretningsmål som skal løses. Samtidig bør innholdsteamet kunne si noe om hvor mye og hva slags innhold siden skal inneholde.

Arbeid med skisser bør ligge i forkant av design og utvikling.

Når teknisk sprint starter, vil forretningssiden ha klargjort nok oppgaver i oppgavelisten (backlog) til at teknisk team kan plukke og estimere arbeidsoppgaver til sin sprint. Hvor ”ferdig” wireframes og design skal være er avhengig av utviklernes kompetanse og i hvilken grad de ønsker å involveres.

2. La prosessen være innholdsdrevet

Hvor mye (eller lite) tekst/innhold som skal inn på en gitt webside setter store føringer for utforming av wireframes og innholdsmaler. En innholdsdrevet utviklingsprosess tar utgangspunkt i at innholdet styrer designprosessen. Målet er å unngå pene Photoshop-skisser som ikke dekker webskribentens tekstlige behov, eller innholdsmaler der interaksjonsdesigneren har lagt opp til påkrevde innholdselementer som ikke gir verdi for brukeren.

For å få til dette er det viktig at prosjektet har innholdsressurser som kan ta de nødvendige grep. Hvilket innhold er utdatert, hva må skrives om, og hva kan slettes? Dette fordrer at webskribentene innehar domenekunnskap og kan skrive godt for web. Fordelene er mange: interaksjonsdesigneren får hjelp til å prioritere innholdselementer og plassering av disse, grafisk designer kan forholde seg til reelt innhold fremfor lorum ipsum, og utviklere unngår redesign av datamodeller og feilaktig implementering av input-felt.

3. Sitt samlet og i åpent landskap

Bruk vegg og tavle for å dele informasjon mellom prosjektets medlemmer.

Dersom hele teamet sitter samlet unngår prosjektet å bruke unødvendig tid på interne avklaringer og informasjonsdeling. Mange problemstillinger blir løst ved at spørsmål stilles i ”løse lufta”, og prosjektleder slipper å koordinere felles møter eller å innhente svar på e-post. Raske avklaringer er viktig for fremdrift i prosjektet.

Samlokalisering og åpent landskap er også med på å skape en felles teamfølelse, samt større engasjement og individuelt ansvar for det enkelte teammedlem. Bruk av tavle med lapper for kø-visualisering gir god oversikt over hva teamets medlemmer jobber med og hvor ”skoen trykker”. Sammen med vegghengte papirskisser og utskrifter av design-filer har man et godt alternativ til elektroniske delingssystemer.

4. Jobb intensivt med stor involveringsgrad

Det er stor forskjell på å jobbe i et prosjekt hvor team-medlemmene er involvert 80% kontra et 20% engasjement.  Tiden som spares ved å slippe å finne ut hva som har skjedd i prosjektet siden sist, og ikke minst lære nye prosjektdeltakere å kjenne, er uvurderlig. Effekten blir større jo flere i teamet som har tilsvarende stor involveringsgrad i prosjektet.

Det tar tid å finne ut hvordan teamet best kan utnytte sine ressurser. Det samme gjelder utforming av prosjekt-rutiner, arbeidsprosesser og gjennomføringsevne. Jo bedre et team kjenner hverandre og seg selv, jo raskere og mer effektivt blir det. Resultatet er flere oppgaver kan løses innenfor hver arbeidsblokk uten av dette går ut over fremdriften i prosjektet.

5. Ha faste morgenmøter

Et sentralt prinsipp i Scrum er lynkorte daglige møter der alle forteller hva de driver med. Poenget er å informere hvert team-medlem om hva som er gjort siden forrige møte, hva som skal gjøres innen neste møte, og hva som eventuelt er til hinder for planlagte oppgaver.

Min erfaring er at morgenmøtet er svært nyttig for hele teamet. Prosjektleder kan informere om nye krav fra markedsavdelingen i forhold til kampanjer, ønsker knyttet til funksjonalitet og innhold, eller omprioriteringer av allerede planlagte arbeidsoppgaver. For teamet gir møtet en anledning til å koordinere felles arbeidsinnsats eller omprioritere egne oppgaver. Sistnevnte er spesielt viktig dersom team-medlemmer blir syke eller prosjektet må påta seg ekstra oppgaver.

6. Gjør kontinuerlige evalueringer

Tilrettelegg for faste punkter der teamet kan evaluere arbeidet de gjør. I et web-basert utviklingsprosjekt er evalueringen av wireframes, papirskisser, grafisk design og innhold vel så viktig som evalueringen av teknisk implementering. Sørg for å iverksette konkrete tiltak på bakgrunn av evalueringen. Start enkelt, og prøv kun en eller to endringer i hver iterasjon. Dette gjør det mulig å se hva som faktisk fungerer i praksis, og å optimalisere prosessen ytterligere.

7. Spill på lag med utviklerne

Sørg for et godt samarbeid mellom team-medlemmene.

Sammenliknet med utviklingsprosjekter for programvare (som ofte består av rene tekniske team), er programmerere ofte i mindretall i web-baserte utviklingsprosjekter. Det er derfor viktig å finne en prosjektmetodikk som også fungerer for forretningssiden og som optimaliserer for helheten.

Det er ingenting i veien med å la utviklerne kjøre Scrum etter boka hvis de ønsker det. Dette krever imidlertid at forretningssiden og teknisk team samarbeider om hvordan backlog skal se ut, og lager klare rutiner for når og hvordan overlevering skal skje. Det bør også være forståelse for at prosjektleder kan omprioritere oppgaver underveis i sprinten. Et midtsprint-planleggingsmøte er et kompromiss som begge parter kan og bør leve med.

8. Bruk en prosjektleder som kjenner kunden og som er 100% involvert

En fraværende prosjektleder resulterer ofte i manglende fremdrift, spesielt hvis prosjektleder også fungerer som kundens produkteier. En god prosjektleder tar ansvar for prioritering av teamets oppgaver, og hjelper til med å booke møter med interessenter for nødvendige avklaringer på forretningssiden.

Prosjektleder er ansvarlig for å holde organisasjonen orientert om  prosjektets fremdrift, og å planlegge kommende lanseringer. Sammen med teamet bør prosjektleder også ta ansvar for å finne ut hvilken arbeidsprosess som fungerer optimalt på bakgrunn av de ressurser som prosjektet har til rådighet. Dette vil vanskelig la seg gjøre dersom prosjektleder ikke er 100% involvert i prosjektet.

9. Bruk kjernemodellen

Kjernemodellen er et tankeverktøy som hjelper kunden med å ta utgangspunkt i nettstedets kjernesider. Hensikten er å definere konkrete brukerbehov og forretningsmål med utgangspunkt i de optimale informasjonsenhetene på nettstedet. Modellen hjelper til med å prioritere krav og sette fokus på hva som er viktig, og fungerer således ypperlig som et diskusjonsgrunnlag med markedsområdene og øvrige interessenter.

I tillegg til selve ”kjernen” inkluderer modellen veier inn (finnbarhet) og veier ut (konvertering). Dette gjør at teamet må tenke bredere enn det som er normalt ved tradisjonell informasjonsarkitektur, og at prosjektet også setter fokus på eksternt markedsmateriell, søkemotoroptimalisering, calls to action, analyse og salg/konvertering.

10. Lanser nettstedet stykkvis fremfor ett ”big bang”

Test og feilretting tar alltid lengre tid enn man tror, og lansering av et nytt nettsted kan raskt bli en smertefull prosess. Dersom det fokuseres på å utvikle og optimalisere deler av et nettsted om gangen, blir risiko mindre samtidig som teamet får mulighet til å gjøre kontinuerlige forbedringer. Ved å gjennomføre brukertester på nylig lanserte sider kan eventuelle problemområder forbedres samtidig med at nye sider lanseres.

Stykkvis lansering av et nettsted vil også gi innholdsarbeidet riktig fokus. Ved å bruke virkelige data er det enklere å se om løsningen dekker reelle behov, og at disse samsvarer med forretningssidens krav. En positiv effekt er at arbeidet med publiseringsrutiner og innholdsproduksjon settes i gang på et tidlig tidspunkt. I tillegg er det enklere å involvere kunden i hele prosessen, fra start til slutt.

Lær hva som funker av Norges og verdens fremste eksperter

På årets Webdagene er det satt av en hel dag til diverse workshoper. Her kan du blant annet lære mer om innholdsstrategi og webanalyse. For mer informasjon se www.webdagene.no.

Standard metodikk for interaksjonsdesign må komme i tillegg til scrum dersom man ønsker gode resultater

Det har blitt svært vanlig å kjøre webutviklingsprosjekter som en Scrum-prosess (også kaldt smidig eller agile). Jeg vil anta at det er mange som er inne i ett av de første scrum-prosjektene sine og strever med å finne ut hvordan det gjennomføres på beste mulige måte. Dessverre er det vanlig at man ”glemmer” viktige aspekter ved det å lage gode nettsider i overgangen til scrum.

I innsalg av scrum-metodikken settes den ofte opp mot et tenkt stort softwareutviklingsprosjekt styrt etter vannfallsmetoden. Det er lett å sitte igjen med inntrykket av at det å skrive spesifikasjoner, inkludert alle andre former for planlegging, fra nå av er gammeldags. Dersom man bare setter ned et team til å begynne på kodingen med en gang, og forholde seg smidig til endringer underveis vil alt bli bra. I praksis vil det ikke fungere akkurat på den måten.

Gode webløsninger krever mer enn å produsere kode

Utforsk ulike konsept før du starter å gå i en rettning. Det er bedre å snu tidlig enn å snu sent.

Det er nok riktig at det ikke er hensiktsmessig å spesifisere alle tekniske funksjoner i starten av et prosjekt, når man vet minst. Men det nytter heller ikke å løpe av gårde dersom man løper i gal rettning. Jeg mener scrum er en god metodikk for selve arbeidet med teknisk koding. Men det er mange oppgaver rundt det å lage et godt nettsted som ikke er knyttet direkte til det å produsere kodelinjer.  Det kan f.eks. være vel så viktig å finne et konsept som treffer målgruppen, definere hvilke verdier en egentlig ønsker å oppnå med nettstedet, legge strategier for innholdsproduksjon, osv.

Det er ikke nødvendigvis hensiktsmessig å presse alle slike oppgaver inn i en struktur med ukentlige sprinter der målet er å produsere ferdig kode. Begynn heller med noen av disse oppgavene en stund før resten av scrumteamet setter i gang for fullt.

Scrum er raskt, men ikke raskt nok
I scrum går kodingen raskt. På 1-2 uker blir funksjonalitet laget og gjerne publisert. Tanken er at scrumprosessen skjer etter iterasjoner. Ved å teste ut det man har laget, kan man gjøre endringer og lage nye og bedre versjoner. Men i praksis blir det til at man i iterasjonene gjør små justeringer i stedet for å lage helt nye og forbedrede versjoner av funksjonalitet. Etter å ha investert en uke utviklingstid føler man seg tross alt litt budet til å beholde det som er laget.

Skisser er raskere å lage enn kode og er en viktig del av utviklingen.

Det å stadig forbedre nettsider gjennom flere iterasjoner er ikke nytt med scrum. Det er vanskelig å treffe 100% første gangen, så dersom man ønsker å lage virkelig gode nettsider er det nesten nødvendig å prøve og feile noen ganger. Men for at man virkelig skal ha tid og råd til å lage mange versjoner, bør de første versjonene være skisser som bare tar noen minutter å lage. Prototyper kan lages mer eller mindre detaljert avhengig av hilket stadium man er i. Min erfaring er at skisser og enkle prototyper fungerer bra som dokumentasjon i et scrumprosjekt. Det er raskere å produsere prototyper enn kode, og samtidig helt nødvendig for å oppnå høy kvalitet på sluttproduktet raskest mulig.

Dette bør du gjøre før kodingen starter:

1. Skisser løsninger, gjerne raske udetaljerte skisser, og gjerne mange av dem.
2. Snakk sammen om løsningene
   Samle sammen interessenter, diskuter løsningene og velg ut de beste ideene.
   Så lenge man har noe konkret å se på, er det bedre å diskutere løsningen tidlig mens alle muligheter ligger åpne enn i det koden skal skrives.

   

3. Pass på at den informasjonen du har om mål, brukere osv. tas med når løsningene vurderes.
   Vis gjerne løsningene til brukere.
4. Detaljer ut de beste forslagene.
5. Tegn større tegninger og færre av dem. Lag animasjoner eller bruk andre enkle prototypingsteknikker dersom interaksjon er en viktig del av brukeropplevelsen.

Bilde av Stalin

Hva er den beste måten å kjøre et webprosjekt på? Dette er noe vi stadig diskuterer i NetLife og vi har ikke fasiten. Ikke overraskende diskuteres dette også i det store utland, det vil si på Future of Web Design i London.

Bakgrunnen er at i de fleste prosjekter går 90 % av energien med til andre ting enn å jobbe med design og utvikling av selve nettstedet. Politikk, mer eller mindre effektive møter, argumenter og utredninger for å overbevise folk. Og, når du er ferdig lurer du litt på hvorfor resultatet ble som det ble. Så hvordan løser man dette:

Danny Somekh har en løsning: Kjør korte, intensive prosjekter inspirert av smidig metodikk. Redesign nettstedet ditt på 3 uker i stedet for 1 år.

Hva krever dette?

• Kunden må være svært engasjert og villig til å sette av all tid disse ukene
• Teamet må være “Dream team” – det er bare å ringe oss
• Ikke bruk tid på å skrive kravspesifikasjoner: gjør alt visuelt. Lag prototyper kjapt.
• Involver brukerne underveis
• Leveranser hver dag
• Kjør front end koding og visuelt design samtidig. Dette er to sider av samme sak
• Lag noe på 3 uker. Få feedback fra brukerne og start videreutvikling etterpå

Lytt til Danny Somekh’s 10 minutters foredrag.

Sabrina Dent mener problemene oppstår fordi vi som utvikler webløsninger er altfor demokratisk anlagt. Løsningen: Den stalinistiske metoden for webdesign.

• Ikke gi kunden valg. Ikke presenter 3 forslag og la kunden bestemme. Det er du som er eksperten! Gi kunden det ene forslaget som er det beste.
• Just do it! Anta at du har makt til å gjøre noe inntil noen sier at du ikke har det.
• Just say No! Kan vi gjør fonten litt mindre? Nei. Litt mer oransje? Nei. 3 nivåer i venstremenyen? Nei. Kunden vil ofte bare ha et nei og aksepterer dette. I 2 av 10 tilfeller vil kunden insistere og da forstår vi hva som virkelig er viktig for dem. For å gi noe til kunden kan du lage logoen litt mindre enn du selv syns er passe. Når kunden vil ha logoen større, sier du ja.

Er dette mulig? 3 ting må være til stede:

1. Du må ha erfaring nok til å kunne improvisere underveis
2. Du må ha selvtillit
3. Sist, men ikke minst “you better not suck”

Lytt til hele foredraget til Sabrina Dent

Jostein Magnussen er enig med begge, men prosjektmetodikken må selvsagt tilpasses den enkelte organisasjon. Min erfaring:

• Intense, korte prosjekter med en urokkelig tidsfrist er ofte de beste og de som gir best sluttresultat. Prosjektgruppen får energi og beslutningspress, pluss at vi unngår problemet med at vi alle glemmer 50% til neste møte
• Små dedikerte prosjektgrupper med 80 – 100% tid på prosjektet er mye mer effektivt enn store grupper der alle har 30% tid
• Beslutninger bør kunne tas i prosjektgruppa eller ved å stikke hodet inn på kontoret til prosjekteier