kunder i aktive prosjekt/forvaltning, 6 interne product owner proxys, to team og tre backlogger – kan det likevel ligne på Scrum? Kristin Wulff, leder for Webkonsulentgruppa i Kantega Trondheim, informasjonsarkitekt med hovedfag i psykologi

Fakta Kantega –66 ansatte, –Oslo + Trondheim –Ansatteeid med like eierandeler Trondheim, Webkonsulentgruppa –16 ansatte –5. januar 2009: lean, 9. februar: Scrummish –Bedrete resultater på økonomi, ansattetilfredshet, kundetilfredshet –Småoppgaver og større prosjekter for eksisterende kunder (forvaltning) –Små og store prosjekter for nye kunder (for eksempel Norsk Kulturminnefond) –Skreddersøm + CMS Lean –70 % booking (satt av tid til div. småoppgaver) –Ressursplanlegging på teamnivå –Teamene eier oppgavene –Jobber med kundene for å få avtaler som gjør kunnskapsutvikling underveis mulig

Scrummish Scrum (The Nokia test) : –There is a product backlog prioritized by business value –The product backlog has estimates created by the team –The team generates burndown charts and knows their velocity –You know who the product owner is –There are no project managers (or anyone else) disrupting the work of the team Scrummish –Daglige stå-opp-møter –Én ansvarlig for hver Product backlog, og den er sortert etter diskusjoner med kundene + internt –Teamene estimerer – men små oppgaver tar vi utenom –Én Scrum master for hvert team –Team X: to ukers sprinter –Team Y: stort sett tre uker –Sprint demo gjennomføres internt (som regel) –Sprint retrospektiv og planlegging gjennomføres, men planlegging uten Product Owner, bare med PO proxy –Forholdsvis stabile team

Erfaringer – Product backlog Februar - April: To team med balansert fordeling av kundene –Ok, men én kunde mye større enn de andre –Tilbud fordeles med ”annenhver”, gjør at mange blir involvert i tilbudsskriving (bra erfaring, men tar ekstra mye tid) April – September: Team Y har én kunde, Team X har én mellomstor kunde + ”resten” –Team Y blir sårbare for ”beslutningsstopp” hos kunden –Team X får mange småoppgaver September – nå: Team Y har en product backlog for sin store kunde + er med i felles product backlog, Team X har én product backlog for den mellomstore kunden + er med i felles backlog –Vanskelig å få Team Y til å se felles backlog. –Team X har Trondheim kommune (mellomstor kunde) som har fått budsjettinnsparinger. Dermed får de tid til ”hele” felles backlog.

Erfaringer – Product owner proxiy Vanskelig, vanskelig, vanskelig… Ikke vanskelig: for oss å bli enig om prioriteringer mellom kundene Vanskelig: å få kundene inn Oppgaver der det har gått ganske bra: –Nytt nettsted for eksisterende kunde: designer + utvikler med kunden som product owner (men i møter for seg, og ikke med i sprintplanlegging). Utfordring: tydeliggjøring av kundens forventning til framdrift –Nytt nettsted for eksisterende kunde: 2 utviklere + product owner proxy/tester Oppgaver der vi sliter: –Kundens product owner ”forsvinner” i perioder: svarer ikke på telefon eller mail, dermed får vi ikke godkjent/bestilt oppgaver vi har estimert –Forvaltning av flere kunder i samme sprint: vanskelig å holde energien oppe. Blir en pragmatisk fordeling av oppgaver, ikke en ”vi må klare dette”-følelse

Framover Hvordan skal vi få mer energi inn i sprinten? Kan vi ha så korte sprinter at vi bare har én kunde i sprinten? Kan vi få knyttet Product owner nærmere til prosessen uten at de knytter seg til én utvikler? Bør vi kalle Product owner Proxys for Product manager isteden? –Product owner er alltid kunden –Product manager er den hos oss som er ansvarlig for kvaliteten på produktet vi leverer –Scrum master er ansvarlig for prosessen Estimering av store oppgaver – hvor mye skjer før sprintplanleggingen, hvor mye skjer i?