Warstory: En kompleks og omskiftelig verden

Når et projekt er i den indledende opstart og man som område prøver at sætte rammerne for det fremtidige samarbejde er der mange overvejelser der skal gøres. Business case og andet bruges som input til en grov release planlægning og dermed også som input til backlog. Personale fra både forretning og udvikling skal allokeres og roller og ansvar skal placeres. Brugen af near-shore / outsourcing skal afklares og processerne omkring forretning, udvikling og kommunikation mellem alle parter skal overvejes. Alt dette er komplekst nok uden forstyrrelser, men i en omskiftelig verden med skiftende prioriteter kan forstyrrelser udefra ikke undgås. Jeg har besøgt et projekt i opstartsfasen hvor de indledende tanker og milestone planer var lagt.

Første omgang

Første udkast til projekt struktur

Ser man på bemandingen var der lagt op en struktur som illustreret (fraregnet ledelse). Da jeg møder projektet er near-shore ikke tilknyttet endnu. De har identificeret analytikere, Lead Developer og nogle af arkitekterne. Ledelsen i projektet er kraftigt inspireret af en tidligere succes historie med Scrum i KMD (hvor jeg agerede ScrumMaster 🙂 ) og ligger op til at følge den samme model. Der er god åbenhed og samarbejdsvilje fra alle tilknyttet projektet – også ledelse. Der er enkelte personer i projektet med Scrum erfaring, men det generelle erfaringsniveau ligger på “har hørt om Scrum”. Projektets deltagere har tænkt mange tanker om hvordan udviklingen skal foregå. Noget kommer fra rygter internt i KMD, fra hvad man har fundet på nettet og man har sammenholdt dette med den måde man plejer at arbejde på. I grove træk er planen det at teamet af analytikere (de grønne) gør alt det en Product Owner skal. Indsamle krav, lave prototyper, skrive userstories, prioritere backloggen og meget andet. Lead Developer og Architects står sammen om de tekniske aspekter. De skal stå for at tegne den overordnede arkitektur som illustreres gennem en reference applikation. Review og estimering i story points af backlog items så de er klar til implementering. Ligeledes står de får kvalitetssikringen af kode leveret fra near-shore teams. Ikke urimelige tanker og heldigvis er jeg i stand til at rette de værste misforståelser ind, men det er svært at gå i detaljer omkring en udviklingsproces når der ikke er tilknyttet et Scrum team som man kan sparre med. Det bliver til snak og diskussioner. Der er nu ca 3 uger til det første near-shore team skal starte.

Anden omgang

Backloggen eksisterer, men indeholder kun kæmpe-epics. Jeg fokuserer på at hjælpe analytikere og Product Owner med at opbygge en god backlog med ”små” User Stories i toppen og de større længere nede. Lead Developer og Architects har rigeligt at se til og bliver flittigt brugt som sparringspartnere til backloggen. I fællesskab bliver vi enige om at hvert Scrum team har deres egen backlog og at disse backlogs fyldes fra en central backlog der giver overblik over alle PBI’er uanset hvilket team de er tilnyttet. Som elektronisk backlog værktøj vælger vi Team Foundation Server 2012, som har glimrende understøttelse for denne struktur. Da der er flere teams tilknyttet projektet, vælger vi at indføre en begrænsning. Alle teams skal have fælles Definition of Ready og Definition of Done. Ændringer til disse kan ikke vedtages af det enkelte team, men skal vedtages på tværs af alle teams. Der er nu ca 2 uger til det første near-shore team skal starte.

Tredje omgang

Andet udkast til projekt struktur

Det bliver pludseligt meldt ud at der ikke er noget near-shore team der kan starte alligevel. Et andet projekt i KMD er i krise og skal bruge alle de hænder de kan stampe op af jorden. Det har store konsekvenser for releaseplaner og for moralen på projektet. Mit mål bliver at få gjort op med den foreslåede projekt struktur og derved at få praktisk erfaring med Scrum ind på projektet alligevel. Gode og konstruktive diskussioner mellem alle gør at vi får udfordret hvilke opgaver der skal løftes af de enkelte roller. Vi vedtager i fællesskab en projekt struktur som illustreret. Stemningen er væsentligt forbedret og forventningerne høje. Vi får etableret et Scrum team i Danmark og de opgaver der før gik uden om backlog ender nu i backloggen, prioriteret og styret af Product Owner. En certificeret ScrumMaster findes blandt analytikerne og tager villigt opgaven. Der er nu ca 2 måneder til det første near-shore team skal starte, men implementationen er begyndt og alle i projektet får erfaring med deres roller og Scrum processen.

Fjerde omgang

Vi har nu bevæget os hen over sommerferien og sådan en periode er fuld af overraskelser. Roller er åbenbart slet ikke så faste som først antaget. Den eksisterende ScrumMaster bliver Product Owner og den eksisterende Product Owner skifter til fuldtids-analytiker En deltids-allokeret person bliver fuldtids-allokeret til projektet og får i al hast en ScrumMaster uddannelse for at varetage ScrumMaster rollen. Nogle af analytikerne skifter afdeling. At min tid med projektet som første prioritet stort set er slut, gør ikke situationen nemmere. Heldigvis er alle ved godt mod og god sparring med de nye rolle-ejere gør at alt er klart til at near-shore teamet starter. Der er nu under 2 uger til det første near-shore team skal starte.

Femte omgang

Bemandingen virker stabil, udviklingen viser fremdrift og der forbedres iterativt på processen. Min rolle er nu at agere sparringspartner og måske kigge forbi og facilitere et retrospective. Jeg ser frem til at følge med i projektet. Near-shore teamet har kørt 2 sprints synkront med teamet i Danmark. (Detaljerne i et setup med flere teams, heraf nogle near-shore må vente til et andet indlæg)