Introduktionsutbildning inom NyA

En presentation över ämnet: "Introduktionsutbildning inom NyA"— Presentationens avskrift:

1 Introduktionsutbildning inom NyA
Rasmus Lilja Introduktionsutbildning inom NyA Skriv upp frågor och gör en ”parkeringsruta”. Starta upp Confluence och NyA Structure. Måste hålla tiden denna gång! Organisation och arbetssätt

2 Vad ska vi prata om idag? Våra olika grupper och råd Vår organisation
Vad vi vill uppnå med den pågående omorganisationen Hur vi planerar utvecklingen tillsammans Hur vi jobbar med paket Upplägg och syfte med paketworkshops, Big Room Planning och Produktägarforum Varför vi planerar tillsammans – och hur det upplevs Hejsan välkomna hit igen allihop! 1,5 timme Idag kommer vi att plocka upp tråden från genomgången av våra roller börja med en Kort genomgång av våra olika grupper och råd Vi kommer sedan att gå vidare till att titta på vår organisation. Jag vet att den organisationsskiss vi ska titta på börjar bli väldigt uttjatad vid det här laget, men jag tänkte att vi snabbt skulle titta på den eftersom den är så tätt sammankopplad med våra roller som vi övergripande gick igenom vid det första introduktionsmötet vi hade. Vi ta även en titt på vad vi vill uppnå med den nya organisationen och varför vi genomför den omorganisation som vi är helt uppe i. Som ni vet finns det mycket kvar här att diskutera innan den nya organisationen sitter, och detta är något vi kommer att fortsätta att gnugga under resten av det här året. Vi kommer sedan gå vidare till att titta närmare på hur vi planerar utvecklingen tillsammans under den så kallade inkrementplaneringsprocessen. Vi ska prata mer om vad ett paket är, varför vi jobbar med paket, och följa med ett paket på resa från idé till att det går ut i produktion. Under paketresans gång kommer vi även gå igenom Upplägg, syfte och mål med paketworkshops, Big Room Planning och Produktägarforum. Om vi hinner kommer vi kort prata om varför vi gör en gemensam planering och hur detta upplevs av NyA-förvaltningen och utvecklingsteamen. Och som alltid - ställ gärna frågor under utbildningens gång! Förutom att räta ut eventuella frågetecken är det är väldigt bra input till oss om vad vi skulle behöva förbättra och förtydliga i vårt fortsatta arbete tillsammans.

3 Grupper och råd Okej, ska vi ta och sparka igång? Vi tar som sagt och plockar upp tråden från vårt första introduktionsmöte och börjar med att titta övergripande på vilka huvudsakliga grupper och råd det finns.

4 Systemstrategiska gruppen
Gemensamt råd för NyA och Ladok Zäta och Mauritz sammankallande Studieadministrativa chefer Jag tänkte vi skulle börja med något nytt och fräscht! Vi har ett helt nystartat råd som kallas ”Den systemstrategiska gruppen”. Syftet är att utgöra en brygga mellan NyA ocj Ladok på en lite mer strategisk nivå och leds av Zäta och Mautitz och där ingår ett antal SA-chefer. NyA och Ladok har ju på många sätt samma användare ute på högskolorna och för dem kan det nog ibland vara konstigt att dessa system är två olika. Därför prata om gemensamma frågor. Nämn också den systemstartegiska gruppen. Helt nystartad. SA-chefer? Leds av Zäta och Mauritz på Ladok3.

5 Förvaltningsrådet (externa deltagare)
Rådgivande organ, bland annat i arbetet med förvaltningsplan och förvaltningsstrategi Utses av SUHF Representerar lärosätena Att förvaltningsplanen stödjer förvaltningsstrategin Omvärldsbevakning Hämta in krav och önskemål på förvaltningen av NyA från universitet och högskolor Förvaltningsrådet är rådgivande organ i arbetet med förvaltningsstrategi och förvaltningsplan. Systemansvarig är ordförande. Rådet bemannas med ca 6 personer från lärosäten. SUHF utser dessa lärosätesrepresentanter. Ett rotationssystem ska tillämpas där varje person sitter maximalt tre år i följd. Mötesfrekvens: Vid behov. Minst ett möte vid framtagning av förvaltningsstrategi samt ett möte för avstämning av förvaltningsplan. Ansvarsområden: Rådgivande vid framtagning av förvaltningsstrategi. Rådgivande vid framtagning av förvaltningsplan. Följa upp att förvaltningsplan följer förvaltningsstrategins intentioner. Är vi på rätt spår? Delta i omvärldsbevakningen och inhämta krav och önskemål på förvaltningen från universitet och högskolor.

6 Förvaltningsgruppen (interna deltagare)
Samordnar och följer upp det praktiska förvaltningsarbetet Förvaltningsledare (verksamhet och teknik) Driftansvarig Releaseansvarig Förvaltningsgrupp Förvaltningsgruppen samordnar och följer upp det praktiska förvaltningsarbetet. Verksamhetens systemansvarig är ordförande i gruppen. Därutöver deltar teknisk förvaltningsledare, driftansvarig, releaseansvarig samt de verksamhets- och teknikspecialister som krävs för att ha tillräcklig sakkunskap på mötet. Mötesfrekvens: Var 14:e dag. Ansvarsområden: • Planera och leda det operativa förvaltningsarbetet. • Samordna överlämningspunkterna för processerna för information, produktion, drift och förvaltning. • Tillsätta gemensamma berednings- och arbetsgrupper. • Kontinuerligt följa upp förvaltningsarbetet.

7 Vår utvecklingsorganisation
Det var några av våra roller och grupper – nu ska vi gå vidare till att titta närmare på hur rollerna samspelar inom utvecklingen av NyA. Säg nu till om ni tycker att detta är tjatigt – då går vi vidare! Sedan i somras har vi arbetat med att etablera en ny organisation. Innan vi berättar om den nya organisationen tänkte jag ge en kort bakgrund till hur det har sett ut hittills.

8 Spårens referensgrupper
Produktägare Kravanalytiker Verksamhets-specialist Sökandeteamet Produktägare Kravanalytiker Verksamhets-specialist Produktionsstyrningsteamet Verksamhets- analytiker Ver Produktägare Kravanalytiker Verksamhets-specialist Infrastrukturteamet Produktägare Kravanalytiker Verksamhets-specialist Handläggningsteamet Produktägare Kravanalytiker Verksamhets-specialist Institutionsanvändarteamet Som ni kanske vet så har NyA under några år varit organiserat i ett antal spår. Respektive spår har bestått av en produktägare och ett team med utvecklare. Vi har även haft kravanalytiker samt verksamhetsspecialister (alltså referensgrupper och lärosätesrepresentanter) som varit knutna till spåren. Behov av förändring! Att organisera utvecklingen inom NyA på detta sätt har fungerat bra under några år, men på senare tid har vi känt att det inte riktigt fungerar optimalt på vissa punkter: Stuprör – svårt att ibland lyfta blicken över spårgränserna och se hela systemet Produktägarna ibland lite väl långt in i utvecklingsteamen. Definierar lösningarna (bör ligga mer på teamet att ta fram den faktiska lösningen medan produktägaren mer ska stå för de övergripande kraven). Produktägaren får då mindre tid att vara produktägare (det vill säga att tänka framåt och ha tentaklerna utåt för att suga in verksamhetens behov) Teamen bli väldigt beroende av produktägaren i beslut om hur saker ska utvecklas Produktägarrollen blir väldigt pressad och personberoende Verksamhets-specialist Produktägare Teknikteamet

9 verksamhets-analytiker verksamhets-analytiker
Områdets referensgrupper Område: Sökande Verks.spec. Spår: Sökandeprocessen Produktägare: Spår: Kom. m sökande Verks.spec. TEAM TEAM Krav-/ verksamhets-analytiker Gem. teknisk resurs Verks.spec. Verksamhets- analytiker Ver Gemensam teknisk resurs: TEK Område: Produktionsledning Spår: Lokal styrning Verks.spec. Produktägare Spår: Nationell styrning TEAM TEAM Verks.spec. Krav-/ verksamhets-analytiker Gem. teknisk resurs Verks.spec. Verksamhets- analytiker Ver Område: Handläggning Gemensam teknisk resurs: TEK För att komma till rätta med detta genomför vi just nu en omorganisation av förvaltnings- och utvecklingsorganisationen för NyA. Framöver siktar vi på att organisationen ska se ut så här. Den nuvarande spårindelningen justeras något och grupperar de nya spåren i tre produktägarområden. De tre områdena är: Sökandeområdet – produktägarområdet för sökande är uppbyggt av spåret för Sökandeprocessen som omfattar funktionaliteten på Antagning.se/Universityadmission.se, samt spåret för Kommunikation med sökande som syftar till att hålla ihop alla sätt som systemet och systemets användare kommunicerar med sökande Produktionsledningsområdet – produktägarområdet för produktionsledning är uppbyggt av spåret för Lokal styrning vilket omfattar funktionalitet som huvudsakligen är inriktad på målgruppen produktionsansvariga på lärosäten, samt spåret för Nationell styrning vilket omfattar funktionalitet för central produktionssamordning och systemdrift. Handläggningsområdet – produktägarområdet för handläggning omfattar spåret för Beredning som hanterar funktionalitet för förberedande handläggning inklusive maskinell behörighetsbedömning och meritvärdering (BM), samt spåret för Beslut som omfattar funktionalitet för sådan handläggning som sker efter BM på institution och på antagningsavdelning på lärosäte eller på UHR. Varje produktägare kommer att ha ansvar för två spår och två utvecklingsteam. För att samla in krav och utreda behov kommer vi fortfarande ha kravanalytiker men vår tanke är att de ska kunna fungera som kravanalytiker lite bredare över systemet jämfört med enbart inom spåren. Vi får därmed fler verksamhetsanalytiker. I den nya organisationen vill vi även fortsättningsvis att produktägare och övriga kravutredningsresurser ska ha tät och regelbunden kontakt med flera olika lärosäten. Utöver denna lärosäteskontakt vill vi utöka gruppen verksamhetsspecialister, det vill säga representanter från lärosätena som kan hjälpa produktägare och team i det dagliga utvecklingsarbetet. Det kan exempelvis handla om att delta på workshoppar, testa prototyper eller att svara på frågor från utvecklare under utvecklingsarbetet. Det innebär alltså att UHR fortfarande vill hyra resurser från lärosätena, men fler personer och på lägre omfattning än tidigare. Det är viktigt att dessa personer huvudsakligen är användare av systemet och därigenom kan bidra med verksamhetens aktuella och konkreta behov och därigenom hjälpa utvecklingsorganisationen att skapa reell nytta i antagningsverksamheten. TEK-teamet blir en gemensam teknisk resurs som understödjer de övriga teamen. Utgångspunkter för den nya organisationen Tvärfunktionella team Vi ska bygga vidare på principen om tvärfunktionella team, dvs. team som ansvarar för hela processen att definiera, bygga och testa mjukvara som motsvarar verksamhetens behov. Utvecklingsteamen ansvarar för att ta fram lösningsförslag. För att teamen ska kunna ta fram lösningsförslag krävs det att produktägaren förstår och kan kommunicera verksamhetens behov till teamet, samt att teamet själva har en löpande direktkontakt med relevanta representanter för verksamheten (verksamhetsspecialister). Detta är ett arbete som vi har påbörjat och som vi behöver arbeta vidare med tillsammans med ITS för att hitta en modell som passar oss. Teamen/Scrum Master ansvarar också för att driva utvecklingsprocessen, med backlog refinement/grooming, sprintplaneringar, retrospektiv och demos, samt för samordning med övriga team. Renodling av produktägarrollen Produktägaren ansvarar för att ha en vision och mål för sitt delområde som ligger i samklang med resten av NyA. Produktägaren ansvarar för att förstå verksamhetens behov och att kommunicera dessa till teamen. Produktägaren ansvarar även för att sätta upp mål för inkrement och sprint samt stämma av resultatet mot dessa mål. Det är dock inte produktägarens roll att ta fram lösningen till behoven eller att utreda och svara på detaljfrågor kring kraven. Vi behöver även fortsättningsvis kvalificerade krav-/verksamhetsanalytiker som kan hjälpa produktägare och team med utredning och analys, i kombination med att teamen har direktkontakt med verksamhetsspecialister. Stärka upp med systemövergripande utredningsresurser Verksamhetsanalytiker! Förvaltningsledningens roll är att få hela orkestern att spela tillsammans! Skapa förutsättningar! Spår: Beredning Produktägare Verks.spec. Spår: Beslut TEAM TEAM Verks.spec.

10 Mål med ny organisation
Bättre utnyttjande av utvecklingsteamens kompetens Ökad direkt användarmedverkan i utvecklingsarbetet Bättre samordning av spårövergripande utveckling Ökat samarbete i hela NyA-förvaltningen Utvecklingsteamen är experter på att ta fram effektiva systemlösningar till verksamhetens behov och problem Genom att ”riktiga användare” involveras direkt i utvecklingsarbetet säkrar vi att de systemlösningar som tas fram motsvarar de reella behoven hos användarna Samordningen underlättas av att vi har färre produktägare och att dessa sitter tillsammans. Dessutom utökar vi stödet på övergripande nivå med ”satsningsansvariga” som håller samman planering över flera områden Genom att vi sitter tillsammans i verksamhetsförvaltningen underlättas ett dagligt samarbete och kommunikation och att vi lättare kan hantera uppkomna problem

11 Verksamhetsanalytiker
Områdets referensgrupper Område: Sökande Verks.spec. Produktägare Spår: Sökandeprocessen Spår: Kom. m sökande Verks.spec. Sökande-teamet ”Produktägarstöd”/kravanalytiker Gem. teknisk resurs Verks.spec. Verksamhetsanalytiker Gemensam teknisk resurs: TEK Område: Produktionsledning Produktägare Spår: Lokal styrning Verks.spec. Spår: Nationell styrning Infra-teamet Verks.spec. ”Produktägarstöd”/ kravanalytiker Produktions- styrningsteamet Gem. teknisk resurs Verks.spec. Verksamhets- analytiker: Rekrytering pågår Ver Område: Handläggning Gemensam teknisk resurs: TEK För att skapa en mjukare övergång till en ny organisation behåller vi de nuvarande teamen med sina nuvarande ansvarsområden (AF). Produktägaren har även kvar kravresurser inom sitt område för att få stöd under tiden teamen bygger upp sitt nya roll att mer stå för lösningen ”på egen hand”. Rekrytering pågår även av en produktägare för handläggningsområdet samt av två nya verksamhetsanalytiker. Men som ni vet är vi ju långt ifrån hemma ännu när det gäller den nya organisationen. Vi fortsätter att diskutera teamens nya roll och måste rekrytera fler referenspersoner som vi kan fråga och rådgöra med under utvecklingens gång. Detta så klart vi kommer att fortsätta att arbeta med under hela året. Den 6 april ha en heldagsworkshop då vi ska diskutera våra roller och arbetssätt tillsammans med scrum mästarna och produktägarna. Referenspersoner till NyA-webben och handläggningen. Har ni några tankar kring den nya organisationen? Spår: Beredning Verks.spec. Spår: Beslut Produktägare ”Produktägarstöd”/ kravanalytiker Verks.spec. Handläggnings- teamet Institutions-användarteamet

12 Så här jobbar vi tillsammans!
Det var det om den nya organisationen – något vi som sagt kommer att återkomma till kontinuerligt under det här året. Hur planerar vi då utvecklingen inom NyA? Parallellt med omorganisationen har vi även byggt upp ett nytt sätt att arbeta som då ska gå ”hand-i-hand” med den nya organisationen. Själva hjärtat i detta nya sätt att arbeta är något som kallas för Big Room Planning som fått stå som representant inte bara för ett nytt sätt att arbeta utan även hur vi hur vi förhåller oss till varandra. Detta trots att själva Big Room-mötet som vi håller fyra gånger om året egentligen bara är en del av den process som vi börjat jobba efter.  Så jag tänkte börja med en kort presentation av processen för hur vi övergripande planerar utvecklingen inom NyA (där Big Room Planning ingår som en del). Denna process har vi går under det snärtiga namnet inkrementplaneringsprocessen. Jag kommer sedan gå vidare in och berätta lite mer om bakgrunden till VARFÖR vi valt att satsa på detta arbetssätt. Jag kommer sedan gå in på utvärderingen av Big Room Planning som metod och presentera några större områden, både vinster med den nya planeringsprocessen men även det som inte upplevs lika positivt.  Men innan vi går in på detta tänkte jag skrämma er lite med den här bilden och bara översiktligt beskriva hur vi planerar utvecklingen inom NyA sedan ungefär ett år tillbaka.

13 Hur planerar vi utvecklingen inom NyA?
BRP BRP BRP BRP Inkrement 1 Inkrement 2 Inkrement 3 Inkrement 4 S1 S2 S3 S1 S2 S3 S1 S2 S3 S1 S2 S3 Bereda paket Bereda paket Bereda paket Bereda paket Paket-WS Paket-WS Paket-WS Paket-WS Inom NyA arbetar vi med så kallade paket och Big Room Planning för att planera utvecklingen av systemet. Vi delar upp utvecklingsfaserna i inkrement som var och en består av tre sprintar. Varje inkrement inleds med en Big Room Planning där vi tillsammans planerar de tre nästkommande sprintarna. Inför varje Big Room Planning har vi beskrivit och värderat olika utvecklingsinsatser som paket under en workshop. På detta sätt får NyA-systemet en utvecklingspuls. Paketworkshop Första steget i planeringsprocessen inför ett nytt inkrement är en så kallad paketworkshop. Inför en paketworkshop har vi beskrivit vad vi vill utveckla kort och kärnfullt. På paket workshopen presenterar vi sedan paketen för varandra och värderar dem tillsammans. En viktig del i förberedelserna inför en paketworkshop är att vi beskriver Vid mötets slut får vi då med oss: En gemensam NyA-backlog för nästa inkrement Prioriterad, dvs rangordnad, lista över paket Som vi tror vi kan göra inom inkrementet Teamallokering – vilket team tar vilket paket Prioritering av paket med WSJF Prioriteringsmetod WSJF (Weighted Shortest Job First)  används bland annat inom ramverket SAFe. Förberedelser inför ett Big Room Planning De paket som väljs ut tas sedan med till ett Big Room Planning-möte. Innan själva Big Room-mötet ska teamen förbereda de utvalda paketen genom att: Komplettera med detaljer vid behov Uppdatera/förfina de grova estimaten Identifiera (om möjligt) tänkbar uppdelning på stories/åtgärder på slogannivå med kort beskrivning Big Room Planning Under själva Big Room-mötet förfinar vi sedan paketen och inkrementplaneringen tillsammans genom: Teamsessioner Nedbrytning av paket Fördelning av stories/åtgärder i sprintar Att sätta upp mål för inkrementet Att lyfta och diskutera risker Big Room-mötet leder fram till en gemensamt beslutad inkrementplan: En inkrementplanering gjord av respektive team, inklusive inkrementmål En inkrementplan med beroenden för NyA De paket som beslutas på Big Room-mötet tas sedan med i utvecklingen när nästa sprint börjar. På detta sätt skapar vi en gemensam bild över vad vi vill utveckla under nästa inkrement (utvecklingsperiod). Produktägarforum Pakten läggs sedan in i NyA structure i JIRA. På detta sätt skapar vi en gemensam backlogg med syfte att ge överblick och följa progress. Vi går sedan igenom backloggen på produktägarforum varje vecka. När paketet rapporteras som färdigt lämnas det över till införandeansvarig på ett produktägarforum. Syftet med produktägarforum är att samordna utvecklingsarbetet inom de olika utvecklingsområdena. Inom produktägarforumet diskuteras pågående krav- och utvecklingsarbete och parallellt utvecklingsarbete inom olika spår kan synkroniseras. Produktägarforumet är också centralt för att möjliggöra en löpande styrning och prioritering av förvaltningsarbetet inom objektet. Ansvarsområden: Koordinera krav- och planeringsarbete som kräver samverkan mellan flera utvecklingsspår Prioritering av utvecklingsinriktning inom spåren utifrån förvaltningsplan, förvaltningsstrategi och aktuella verksamhetsbehov CONFLUENCE: INTRODUKTIONSUTBILDNINGEN – GÅ IGENOM PAKETMALLEN HÄR VISA DOKUMENTATION FRÅN BRP GÅ IGENOM JIRA STRUCTURE

14 Paket för att skapa överblick inom NyA
Förvaltningsstrategi med mål och prioriterade områden Mall för satsningar Mall för paket Förvaltningsplan med satsningar Paket 1 Paket 2 Paket 3 Paket 4 Vad är ett paket? Begreppet ”paket” är väldigt centralt i vår planering. Paket är en klustring av ärenden som hör ihop och som tillsammans levererar ett värde eller en nytta till användarna – en ny funktionalitet av något slag exempelvis. Genom att klustra ihop ärenden och åtgärder till en högre nivå än enskilda ärenden i Jira blir det lättare att få en överblick över vad som är under utveckling och prata om den gemensamt. Kopplar starkt till satsningar och utvecklingsområden i förvaltningsplanen – något vi ska prata mer om på torsdag den 30:e. Ärenden i Jira

15 Paketprocessen – en översikt

16 Förberedelser inför en paketworkshop
Fyll i paketmallen i Confluence Tydlig rubrik – vad vill vi uppnå med paketet? Beskriv paketet kort och kärnfullt Var noga med att även fylla i behov, nytta, ursprung och estimat (värderas under workshopen) Förberedelser inför en paketworkshop Ni kommer ihåg att varje inkrement eller utvecklingsperiod föregås av en paket-workshop. Inför en paket-workshop fyller vi i den mall vi tagit fram för att beskriva paket på Confluence. VISA PAKETMALLEN PÅ CONFLUENCE

17 Syftet med paketworkshopen: välja ut och prioritera paket som vi ska ta med oss till Big Room Planning för nästa inkrement. Vid mötets slut vill vi ha med oss: En gemensam NyA-backlog för nästa inkrement Prioriterad, dvs rangordnad, lista över paket Som vi tror vi kan göra inom inkrementet Teamallokering – vilket team tar vilket paket Paketworkshop På paketworkshopen presenterar vi sedan paketen för varandra. Efter att vi gjort det värderar vi dem efter en särskild metod som vi ska kika på alldeles strax. Vi väljer sedan ut vilka paket vi ska ta med oss till nästa inkrement och gör en grov plan för de nästkommande tre sprintarna (vilket team som kommer att jobba med respektive paket). Vid mötets slut vill vi ha med oss: En gemensam NyA-backlog för nästa inkrement Prioriterad, dvs rangordnad, lista över paket Som vi tror vi kan göra inom inkrementet Teamallokering – vilket team tar vilket paket

18 Prioritering av paket med WSJF
Prioriteringsmetod som används inom (bland annat) ramverket SAFe Ger stöd för i vilken ordning man ska göra utvecklingsåtgärder (”Jobb”) Bygger på jobbets ”vikt” (Weight) i relation till dess ”omfattning” (Duration) Bedömningar av vikt/omfattning sker relativt mellan jobben – man måste inte ha absoluta siffror. Prioritering av paket med WSJF Weigted shortest job first

19 Förklara i stort användar-/verksamhetsvärde,
tidskritiskhet, (hur bråttom är det, finns det en skarp deadline, är det exempelvis en ny lag som börjar gälla som gör att vi måste ändra på något?) riskreduktion/möjliggörande (Teknisk förbättring som skapar möjligheter till ny förbättrad funktionalitet exempelvis). Helena, Tommy och Sanna a kommer att vara med på paketworkshopen den 5 april, bättre att se det live än att gå in på djupet här.

20 Förberedelser inför Big Room Planning
Uppdatera/förfina de grova estimaten Identifiera (om möjligt) tänkbar uppdelning på stories/åtgärder på slogannivå med kort beskrivning Ska i slutändan uppfylla Definition of Ready för paket

21 Definition of Ready för paket
För ett funktionellt paket ska det finnas: Beskrivning av paketets önskade effekt ur ett verksamhetsperspektiv Beskrivning av önskad verksamhetsförmåga Leveransperspektiv Lämplig leveranstidpunkt (senast, tidigast, beroende till andra händelser) Införandekrav Förslag på en minimal funktionell lösning baserad på en "Process- story" Grovt estimerat till maximalt vad som ryms inom ett inkrement Nedbrytningsbart Grov uppfattning om resurs- och tekniska beroenden

22 Big Room Planning Teamsessioner Nedbrytning av paket
Fördelning av stories/åtgärder i sprintar Sätta upp mål med inkrementet Risker Inkrementplan Bygga upp en gemensam inkrementplan Beroenden mellan teamen Scrum of Scrums mitt i teamsessionen Big Room Planning

23 Gemensam inkrementplan
En inkrementplanering gjord av respektive team, inklusive inkrementmål En inkrementplan med beroenden för NyA Gemensam inkrementplan, övergripande mål för inkrementet och för varje team. VISA DOKUMENTATION FRÅN BRP. Plan, mål, risker etc

24 NyA structure – gemensam backlogg
Syfte: skapa överblick och följa progress Genomgång på produktägarforum Två nivåer: Paket Underliggande åtgärder story (bygger progress) GÅ IGENOM JIRA STRUCTURE

25 Paketet färdigt Lämnas över till releaseansvarig (Kerstin Alverholt)

26 Utvecklingspuls Varje inkrement inleds med en Big Room Planning
Input till Big Room Planning tas fram vid Paket-Workshop Releaser löpande under året (inte kopplat till inkrement!) Inkrement 1 BRP Inkrement 2 BRP Inkrement 3 S1 S2 S3 S1 S2 S3 S1 S2 S3 Bereda paket Bereda paket Bereda paket Paket-WS Paket-WS Paket-WS

27 Varför gemensam planering?
Bryta stuprör och få till ett ett helhetsperspektiv Förbättrad modell för stora utvecklingsinsatser som spänner över hela systemet Skapa röd tråd mellan strategi, förvaltningsplan och utveckling av systemet Skapa en snabb samlad överblick över vad som var på gång inom utvecklingen av NyA för tillfället Göra det lättare att kommunicera kring utvecklingen – både internt och externt Göra vårt arbete mer transparent Varför har vi då valt att göra på detta sätt? Nyckelordet här är egentligen inte ”planering” utan nyckeln ligger snarare i att det just är en gemensam planering. Om vi kort backar bandet till för ungefär ett och ett halvt år sedan så brottades vi med några ganska rejäla problem när det gällde förvaltningen inom NyA. Vi jobbade även ganska ”stuprörigt” i våra spår, nästan som om varje spår var en egen produkt, NyA var inget gemensamt system helt enkelt (ni kommer ihåg organisationsbilden över NyA:s olika spår). Vi behövde även utveckla modellen för hur vi skulle tackla stora utvecklingspuckar som spände över hela systemet och alla spår. Hur vi var organiserade gav inget bra stöd för exempelvis SEPA. Vi hade bland annat svårt att se en koppling mellan de prioriterade områdena i förvaltningsplanen och de ärenden som låg i Jira. Inte för att ärendena som teamen jobbade med på något sätt var fel men det var väldigt svårt att gå från detaljerna och få ett snabb samlad överblick över vad som faktiskt var på gång inom utvecklingen av NyA för tillfället. Detta gjorde det ganska svårt att ha gemensamma diskussioner om utvecklingen både internt inom NyA, men så klart även att kunna kommunicera det utåt till exempelvis lärosätena var en rätt rejäl uppgift. Detta sätt att planera gör helt enkelt hela vårt arbete mer transparant – det går att se hur allt hänger ihop på ett bättre sätt nu än tidigare!

28 Fördelar med vårt nya arbetssätt
Bättre helhetsbild över vad som är på gång inom utvecklingen Ger helt nya förutsättningar att kommunicera vad som är på gång inom utvecklingen till användarna NyA ses mer som en gemensam produkt Stor samordningsvinst vid större aktiviteter – planering och arbetsfördelning Produktledning och releaseledning upplever en enorm tidsvinst Förbättrat kontaktnät inom hela NyA-organisationen Vi upplever en starkare ”vi-känsla Vi vidgar varandras vyer med våra olika perspektiv Har det nya sättet att planera utvecklingen gemensamt på detta sätt gett några effekter? Vi utvärderade detta sätt att arbeta innan jul och jag tänkte att jag skulle presentera några axplock från resultaten. Både positiva men också det som upplevts som mindre positiva. Men vi börjar med det positiva! Big Room Planning har definitivt bidragit till en bättre helhetsbild av vad som är på gång inom utvecklingen av NyA-systemet. NyA-systemet ses nu mer som en gemensam produkt jämfört med tidigare då spåren mer upplevdes som en ”egen” produkt. Big Room Planning skapar även helt nya förutsättningar att kommunicera vad som är på gång i utvecklingen till användarna. NyA ses mer som en gemensam produkt och vi vidgar varandras vyer med våra olika perspektiv. Jag skulle även vilja påstå att vi är bra mycket bättre rustade nu rent metodmässigt inför nästa stora utvecklingsutmaning som spänner över hela systemet (ser fram emot det, vad det än blir härnäst). Produktledningen och releaseledningen upplever en enorm tidsvinst – allt samordnas under samma tillfälle istället för spridda kontakter över tid. Inte minst har kontaktnätet förbättrats och i stort upplever vi nu en starkare ”vi-känsla”. Här är även middagen på kvällen är viktig. Det är bra med sociala aktiviteter, inte minst när vi jobbar distribuerat. Bättre relationer skapas när vi träffas!

29 Mindre bra saker Teamen upplever ingen tidsvinst överhuvudtaget
Känsla av att vi blivit mindre agila – planerna känns mer cementerade nu Osäkert om vi levererar mer rätt Vi behöver fortsätta diskutera hur vi kan hitta balansen mellan planering och det agila. Men allt upplevs inte som odelat positivt, och det är väldigt viktigt att lyfta i det här sammanhanget. På frågan om Big Room Planning sparar tid i planeringen går åsikterna isär. Förvaltningsledningen och releaseledningen sparar väldigt mycket tid medan utvecklingsteamen inte upplever någon tidsbesparing överhuvudtaget. Produktägarna står någonstans mitt emellan i sin uppfattning. De känner ingen direkt tidsbesparing, däremot får de mer utväxling på den planeringstid de lägger ner. Det råder lite delade meningar men det finns en känsla av att vi blivit mindre agila i samband med Big Room Planning eftersom planeringen känns mer cementerad nu jämfört med tidigare. Det finns inte heller en säker känsla av att vi levererar mer rätt än tidigare. Vi behöver därför fortsätta att diskutera vad det faktiskt innebär att vara agila och lyfta frågor som: Hur agila ska/kan vi vara? Hur kan vi hitta balansen mellan planering och det agila? När måste vi ha ett gemensamt åtagande och när kan vi vara mer flexibla? Vad behöver vi faktiskt planera tillsammans? Planerar vi in för mycket? Bör vi ha mer luft (mer bas) i planeringen? Det måste finnas plats för att göra om planeringen om det behövs. Nästa giv är att planera på paket workshop PÄ + ScM och sedan träffas gemensamt på BRP för att informera och diskutera.