Reload! A/S Om Reload og proces Præsentation af Reload

Vi er specialister i Drupal Vi er pt. 18 faste folk Reload startede i 2010. Vi bor på Frederiksberg

• Vi er et teknisk konsulenthus, og har de dygtigste Drupal udviklere i DK • Vi outsourcer ikke, idet vi fokuserer på et tæt samarbejde med kunden • Vi har høj faglighed stolthed og en god sjat idealisme Kort om Reload

DR.dk

DR.dk på Drupal Vi har arbejdet på at lave en helt ny webplatform for DR sammen med Peytz (og senere Netcompany) i perioden april 2012 til december 2015. Vi har rundet de 12.000 timer for Reload alene på dette projekt. Langt størstedelen af projektet har vi ageret hovedarkitekter og senior ressourcer.

IDA.dk “Den agile proces fungerer skide godt. Det giver ro i maven, at der er løbende leveringer” Kim Elmose, Digital udviklingsredaktør, IDA

samvirke.dk “Vi er så glade for at arbejde sammen med dem - også selv når projektlederen og jeg diskuterer som et gammelt ægtepar”. “Der findes ikke et Drupal- udviklingshus som er mere kompetent end Reload.” Lotte Malmgren, digital redaktør, Samvirke

“Ret tidligt i forløbet havde vi noget visuelt, som kunne fungere teknisk, hvilket var super fedt.”
 Birgitte Olesen, IT-projektkoordinator, DKT “Det at have designere og udviklere i samme rum og med det samme finde ud af, hvorvidt designet kan implementeres, var fantastisk”
 Anne Tønnes Jessen, systemkoordinator, DKT Det Kongelige Teater - Intranet

Københavns Biblioteker

stofa.dk

desuden TV2, Bonnier, Unicef, Læger uden Grænser, Det Kongelige Teater, De Danske Spejdere, Novasol, Region Sjælland, Kulturstyrelsen og mange andre…

Mød Reload • Se video online på https://vimeo.com/ 112038104 eller reload.dk

Many companies face the paradox of wanting to build a delightful product without knowing if people actually want the product until it’s released. – Chris Bank, UXPin

• Antager at man på forhånd kan regne ud, hvad der skal bygges, og i hvilken rækkefølge, det bedst giver mening • Fungerer derfor fint til simple eller overskuelige opgaver • Har et meget langt feedback loop, og er derfor ikke optimalt til innovative eller komplekse projekter med mange antagelser og ubekendte Den klassiske vandfaldsmodel

• Et godt projekt er ét vi ikke ved hvordan vi skal løse når vi går igang • Et godt projekt bliver vi klogere af • Vi kommer ofte tidligt ind i projekterne og bruger meget energi på at afklare de reelle forretningsbehov, inden vi prøver at løse dem Hvis virkeligheden er simpel, så har I nok ikke brug for Reload! Reloads typiske projektrum

Start with why Vi bruger metoden Impact Mapping for at identificere forretningsmål, aktører, hvordan og hvad der skal laves. Og så bruger vi agile metoder for at levere dette efterfølgende. Vi arbejder altså i højere grad efter forretningsmål end funktionaliteter.

Vælger i os, så vælger i også en proces

No content

Vi kan jo ikke bare udskrive en blanko-check?! - Typisk reaktion fra kunde, sagt i vantro…

• Feedback loop, kommunikation og ansvarsfordeling • Giver gennemskuelighed og transparens Overskrift i en linie • Det giver mening at være agil når man arbejder inden for komplekse problemområder • Løbende forventningsafstemning Hvorfor arbejder vi agilt? Fantastisk video - se den!

En agil udviklingsproces handler om at give mest mulig forretningsværdi for pengene

Det handler om at finde symbiosen mellem forretningsviden og teknisk viden

Viden stiger over tid - fordrer JIT planlægning

Plan Plan Plan Plan Plan "JUST-IN-TIME" PLANLÆGNING Plan Analyse Test Kode Design Release Traditionel (prædiktiv): Planlæg hele projektet på forhånd Scrum (empirisk): Planlæg lidt før projektet og lidt før hvert sprint Analyse Design Kode Test Release Analyse Design Kode Test Release Analyse Design Kode Test Release Analyse Design Kode Test Release Hvad hvis projektet stopper her? Plan Plan Plan Plan Plan

• Fokusér på forretningsværdi • Lav leverancer der kan afprøves i virkeligheden og hurtigst muligt • Prototyping! • Løbende forbedringer i stedet for "løs det hele på en gang" • Lagkagen skal skæres vertikalt og ikke horisontalt Fokus på forretningsværdi, time- to-market og minimumsprodukt (MVP)

Fast scope Agil Transparens "95% færdig" Reel fremdrift er synlig Time to market Langsommere, alt skal designes først Hurtigere, færdiggør ting med størst forretningsværdi først Kvalitet Mindst muligt der opfylder kontrakten Fokus på Total Cost of Ownership (TCO) Fast scope vs agil

Fast scope Agil Projekt fokus Udfør opgaver med mindst mulig indsats Maksimering af forretningsværdi og TCO Ændringer Dyre Gratis Scope Fast Løbende forbedret med de erfaringer der er gjort i projektet Fast scope vs agil

Fast scope Agil Kundeinvolvering Stor indsats i starten og slutningen af projektet Stabil indsats gennem hele projektet Typiske risici Dyrt pga. ændringer, manglende kvalitet Uerfarent team "misbruger" den agile praksis Pris Fast + ændringsønsker Betal kun for udført arbejde Fast scope vs agil

(Quality) Scope (functionality, features) Time (deadline) Resources (cost, budget)

• At have en effektiv agil udviklingsproces stiller en masse krav til resten af organisationen og de omkringliggende beslutningsprocesser • At fordre en agil mentalitet og arbejdsproces kræver stor opbakning i organisationen og specielt i ledelsen • At indføre og køre et scrumforløb som en ekstern konsulentpart har sine helt egne udfordringer - men vi kender dem. At arbejde agilt stiller en masse krav til jeres organisation

• I skal turde at gå efter overordnede mål - og ikke tro at alt kan skrives ned i en kontrakt fra starten • Det kræver kompetente teams, uddelegering af beslutningsmandat og klare mål • Transparens i proces og hurtig feedback giver mulighed for - og kræver - løbende reprioriteringer af de planlagte opgaver At arbejde agilt stiller en masse krav til jeres organisation

• Vi starter med fokus på hvilken reel forretningsværdi vi jagter - og hvordan det er prioriteret. Her er Impact Mapping et godt værktøj. • Vi arbejder langt mere med prototyping - endnu mere iterativt og meget tæt med kunde, udvikler, ux og design. På den måde slipper vi for at kæmpe mod forudintagede forventninger omkring det endelige design. I stedet bruger vi style guides og eksempler. • Endnu større fokus på at lave fremskrivning. Hvad når vi af funktionalitet for pengene? Hvornår er vi færdige? • Risici. Klassisk risiko log i fht. projektet giver ro i maven. Agile projekter hos Reload

• Vi kræver at kundens Product Owner er beslutningsdygtig og sammen med teamet 1-2 dage om ugen • Faste rutiner - typisk 2 ugers sprint, løbende backlog grooming, sprint- planning, -demo og -retrospektiv samt daily scrums • Gode værktøjer - vi sværger til Jira Agile, og vores kunder arbejder også her. • Gode afrapporteringsskabeloner med fokus på MVP Agile projekter i Reload

Lige meget hvor godt et projekt vi laver, så vil det af kunden blive betragtet som en fiasko, hvis vi ikke møder deres forventninger. – Rasmus Luckow-Nielsen, adm. direktør, Reload

Suomisvej 2, 2. sal
 1927 Frederiksberg reload.dk [email protected]