Bortsett fra PI-planleggingsagendaen, er praksisen vedtatt av RTE Scrum of Scrums, dvs. synkronisering av alle Scrum Masters når det gjelder å gjennomgå planleggingsfremdrift og snakke om risikoer og hindringer.
Ved detaljplanlegging i 8-12 uker har det vist seg nyttig å bruke EDUF-metoden (Enough Design Upfront), det vil si å planlegge de neste to spurtene mer detaljert. De resterende spurtene kan inneholde historier på et mer generelt nivå, med fokus på å identifisere avhengigheter. Husk at lag deltar i arrangementer på teamnivå som Sprint Planning i løpet av programtilveksten. Så etter hvert som du lærer mer, vil planene dine sannsynligvis endre seg.
Dag 1 av PI-planlegging
forretningskontekst – Dette er et åpningsmøte for PI Planning hvor bedriftseier eller leder vil presentere informasjon om vilkårene og betingelsene rundt produktet og visjonen til hele produktporteføljen.
Produktsynsløsninger – Produktstyring gir informasjon om gjeldende produktvisjon og viser endringer som har skjedd siden forrige PI-planlegging. De diskuterer også hvordan dagens løsning ser ut, hvordan hver del av produktet (funksjonene) ser ut, hvordan de kommuniserer med hverandre osv.
Visjon om arkitektur og standardutvikling – Systemarkitekter/ingeniører presenterer en visjon om systemløsningsarkitekturen. I tillegg introduserer personen som utfører funksjonen System Architect/Engineer Agile støttepraksis, som testautomatisering, DevOps eller CI/CD.
Planleggingsregler og lunsj – Release Train Engineer presenterer planleggingsprosessen og forventet resultat på slutten av PI-planlegging.
Planlegging i smidige team (1. runde) – Etter at Agile Teams har hørt all informasjonen om Pi Planning og produktet, går de til gruppene sine der den første iterasjonen av planlegging av fremtidige Sprints starter. Agile-teamet jobber sammen med Scrum Master og Product Owner for å utvikle en plan for hver iterasjon av produktet. Under dette arrangementet er Scrum Master personen som tilrettelegger for det smidige teamets diskusjoner og aktiviteter. Under dette arrangementet lager smidige team den første versjonen av planen for det kommende kvartalet.
Et veldig viktig element som er verdt å nevne her er avhengigheter. Når du planlegger funksjoner for fremtidige spurter, kan det hende du finner ut at det smidige teamet ditt trenger støtte fra et annet team for å fullføre oppgavene sine. Derfor, under PI-planlegging, utfører vi to aktiviteter:
- Skap avhengigheter og koordiner prosess- og arbeidssynkronisering med andre smidige team.
- Fullføring av Dependency Board/Program Board mellom smidige team for å gi åpenhet og lette overvåking av endringer i løpet av programmets levetid
Første gjennomgang av planer – Smidige lag presenterer en innledende plan for fremtidige spurter eller hva de laget under planleggingen. De gir også informasjon om mulige planleggingsproblemer, risikoer og avhengigheter. Interessenter, dvs. bedriftseiere, produktledere og andre Agile-team kommenterer eller hjelper til med å avklare problemene som tas opp av Agile-teamet.
Ledergjennomgang av planer og problemløsning – Etter hver første plangjennomgang møtes ledelsen for å diskutere det og finne løsninger for den gitte situasjonen, men også for å forhandle oppgaveomfanget for smidige team. Release Train Engineer (RTE) er ansvarlig for å tilrettelegge for dette møtet og også for å hjelpe til med å finne løsninger, dvs. sørge for at ledelsen utvikler løsninger som kan oppnås av smidige team.
Dag 2 av PI-planlegging
Planleggingskorreksjon (gjennomgang) – Ledelsen presenterer resultatene fra plangjennomgangsmøtet og problemløsningsøkten. Det informeres om endringer i omfanget av planlegging og løsninger på risikoer og problemer.
Planlegging i smidige team (2. runde) – Etter at deltakerne har lært av PI Planning om mulige endringer, går smidige team til gruppene sine hvor de sluttfører planleggingen for fremtidige spurter. I denne delen fullfører Agile Teams arbeidet sitt og forbedrer forholdet til andre Agile Teams.
Endelig plangjennomgang og lunsj – Smidige lag presenterer sine planer for fremtidige spurter (husk optimal planlegging for 4-6 spurter). På slutten av presentasjonen av hver plan gir smidige team informasjon om risikoer og avhengigheter. I tillegg, under dette møtet, søker Agile Team godkjenning fra bedriftseiere for planen deres. Dersom Bedriftseieren ikke aksepterer planen, vil Agile Team få mulighet til å endre/oppdatere den. Etter at endringene er gjort, sendes planen på nytt til godkjenning.
Programrisikoer – Som allerede nevnt rapporterer smidige team også om risiko og problemer. Hver av dem er løst for ikke å være et hinder for å nå målet av smidige lag. For å hjelpe med oppløsning og kategorisering bruker vi ROAM-tilnærmingen (Resolved, Owned, Accepted, Mitigated).
Avstemning om plangjennomførbarhet – Den såkalte tillitsavstemningen gjennomføres praktisk talt på slutten av PI-planleggingen. Hvert agile team bruker hånden sin til å stemme for planen til sitt agile team ved å peke fingeren på et konfidensnivå på 1-5, der 1 betyr at planen vil være praktisk talt umulig å fullføre og 5 betyr at den vil fullføres 100 %.
Endringer i Agile Teams-planer – Om nødvendig gjør smidige team endringer i gjeldende plan i gruppene sine for å minimere risikoer, avhengigheter eller gjøre dem gjennomførbare.
PI Planlegging Retrospective – Arrangementet vil bli ledet av Release Train Engineer (RTE) for å samle informasjon om hva som gikk bra, hva som ikke helt klarte det og hva som kan gjøres annerledes i neste PI-planlegging.
PI Planleggingsresultat
Etter fullføring av PI-planlegging, oppsummerer Release Train Engineer (RTE) og andre Agile Release Train (ART)-interessenter hvert Agile-teams individuelle PI-mål i et sett med PI-mål og bruker dem til å spore fremgang i forhold til å forfølge målene. Programstyret brukes ofte i Scrum of Scrums for å spore avhengigheter og fremgang.
Sist men ikke minst, det viktigste er at Agile Release Train (ART) fortsetter å kjøre PI, sporer arbeidsfremdriften og tilpasser seg etter behov til endringer som skjer etter hvert som ny produktinformasjon blir tilgjengelig. Utførelse av PI starter med at alle Agile-team planlegger sin første iterasjon og bruker PI-planene deres som utgangspunkt.
Så mye for teorien. Hvis du vil se hvordan PI-planlegging ser ut i praksis, har du sjansen nå. Deloittes SAFe-team organiserer en PI-planleggingssimulering hvor du kan oppleve live PI-planlegging i et nøtteskall.
«Guru for sosiale medier. Sertifisert alkoholelsker. Ond musikkfanatiker. Internett-evangelist.»