Agile projekter i Reload - APMA præsentation (Danish)

Præsentation givet d. 20. maj 2015 i APMA - Agile Project Management Association i København.

Oplægget er herunder, men jeg har mest beskæftiget mig med hvordan man overbeviser en kunde/chef om at arbejde agilt, hvorfor det er en god ide og hvilke learnings vi har gjort undervejs.

OPLÆG:
Vi får indblik i de udfordringer Reload har mødt undervejs i deres projekter, og hvordan de har udviklet og justeret deres agile tilgang, så den passer til deres kunders ofte knap så agile verden.

Hvad har været svært og hvor har de mødt de største udfordringer. Rasmus løfter også sløret for deres succescases, hvor det gik galt og hvordan de har draget læring af det.

LINKS i denne præsentation (kan også findes i PDF)
- Mød Reload video: https://vimeo.com/112038104
- Agile Product Ownership in a nutshell: https://www.youtube.com/watch?v=502ILHjX9EE
- Consultancy Scrum: http://consultancyscrum.org/da/
- Impact Mapping: www.impactmapping.org/
- Styleguide til Københavns Biblioteker: http://style.stupid-studio.com/kbhbib/
- Agile that works and the tools we love: https://speakerdeck.com/rasmusluckow/agile-that-works-and-the-tools-we-love

Jobs hos Reload: http://reload.dk/jobs

Transcript

1. Reload! A/S 20. maj 2015 - APMA Agile projekter i Reload Præsentation af Reload
2. • Rasmus Luckow-Nielsen, 36 år • Partner og administrerende direktør i Reload • Baggrund som udvikler, projekt leder og udviklingschef. • Arbejder i dag mest med salg, kommunikation og forbedring af vores processer Hvem er jeg?
3. Vi er specialister i Drupal Vi er pt. 16 faste folk Reload startede i 2010. Vi bor på Frederiksberg Vi vandt en Børsen Gazelle i 2014 … og så elsker vi gode processer!
4. Mød Reload • Se video online på https://vimeo.com/ 112038104 eller reload.dk
5. Kunder Her er et par typiske kunder / projekter
6. Danmarks Radio - DR.dk
7. Sydenergi/Stofa - stofa.dk
8. Ingeniørforeningen - ida.dk
9. COOP - samvirke.dk
10. Københavns biblioteker - bibliotek.kk.dk
11. • 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
12. Hør, HVAD der før gik galt for Reload på agile projekter, og HVORDAN de nu har knækket den agile kode. – Forsiden af APMA.dk
13. Hvem har arbejdet i et agilt projekt? Fx som Product Owner eller Scrum Master?
14. Vi kan jo ikke bare udskrive en blanko-check?! - Typisk reaktion fra kunde, sagt i vantro…
15. • 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?
16. En agil udviklingsproces handler om at give mest mulig forretningsværdi for pengene
17. Det handler om at finde symbiosen mellem forretningsviden og teknisk viden
18. Viden stiger over tid - fordrer JIT planlægning
19. 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?
20. • 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)
21. 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
22. 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
23. 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
24. Fantastisk video - se den!
25. Udfordringerne … og vi har været en del igennem
26. Scrum is simple, but not easy – T-shirt på konference
27. • Vi er gået fra "kaos agilt" • Til "vi gør alting efter (scrum) bogen" • Og er nu endt i en afbalanceret model hvor vi ved hvad der skal skrues på til hvert projekt og kunde - og ikke mindst hvad der er giver mest værdi til processen Fra kaos til forudsigelighed
28. • 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 - se "consultancy scrum". At arbejde agilt stiller en masse krav til jeres organisation http://consultancyscrum.org/da/
29. (Quality) Scope (functionality, features) Time (deadline) Resources (cost, budget)
30. Et projekt der gik galt for os - IDA Mødeportal • Et delprojekt af IDA.dk (vi startede på ida.dk i 2012 og arbejder stadig på sitet) • Vi kunne ikke påvise at vi leverede varen efter de første to sprints (og det var vores egen fejl). • Udfordret af forkert opdeling af opgaver og generel undervurdering af opgavernes kompleksitet og indbyrdes afhængigheder • Nyt scrum-team internt hos os • Projektejerne var en anden del af organisationen, der ikke kendte hverken til os eller til agile udviklingsprojekter. Og vi fik dem ikke ordentligt klædt på. • Projektets Scope og Budget (samt Kvalitet) var reelt set meget tæt på at være "fixed". Dvs. ikke meget råderum at bevæge sig i.
31. Et projekt der gik galt for os - IDA Mødeportal • På baggrund af disse ting forsvandt tilliden til os. 
 Kunne vi nå at lave de planlagte funktionaliteter inden for tid og budget? • Og det er grundlæggende meget svært og belastende at køre et (agilt) projekt uden tillid. • Vi endte med at fikse scope og pris, tage et økonomisk tab og komme i mål • Men det var grundlæggende ubehageligt
32. Hvad lærte vi så? Opskriften på succes for os • Det er virkelig vigtigt at man får klædt kunden - ikke mindst ledelsen - ordenligt på til et agilt projekt. • PAS PÅ når der sker udskiftninger i projektorganisationen - nye folk skal have den nødvendige grundlæggende forståelse for processen. • Sørg for at skære opgaverne således man kan vise fremdrift og succes. Dette er en kunst i sig selv. • Ved større organisationer med mange interessenter og styregrupper, som man ikke er i daglig kontakt til, så giver en mere traditionel afrapportering stor mening. • Vi har efterfølgende introduceret en "sprint rapport" model, som vi har fået meget ros for.
33. Hvad lærte vi så? Opskriften på succes for os • Simple ting som Daily Scrums og fokus på burndowns kan fange mange problemer tidligt. • Det er i min optik nok det sidste man skal give kald på. • Involvér kundens Product Owner så meget som muligt - sørg for at de bliver projektets ambassadør i organisationen. • Product Owners skal have beslutningsmandat og mod til at forsvare beslutninger. • Kræv POs tilstedeværelse - mere er godt! • Jo mere kommunikation desto bedre. Den skal selvfølgelig også være ærlig!
34. • 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 i dag
35. • 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.
 Se også "Agile that works and the tools we love". • Gode afrapporteringsskabeloner med fokus på MVP Agile projekter i Reload i dag
36. ereolen.dk er et kæmpe hit Her gik alt op i en højere enhed og vi løste opgaven på rekord-tid og langt under budget. Og der var ellers et par kommunale chefer der var noget skeptiske. Lige nu lægger vi også sidste hånd på et nyt Intranet for Det Kongelige Teater, og det er vores mest agile projekt til dato! Det tegner også til at blive en stor succes.
37. 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
38. Spørgsmål? Jeg snakker meget, så det har vi næppe tid til ?!
39. Følg os på reload.dk twitter.com/reloaddk facebook.com/reloaddk linkedin.com/company/reload-a-s OBS - vi søger en projektleder lige nu. Se reload.dk/jobs senere på ugen - spred ordet :-)