Introduktionsutbildning inom NyA 2017-03-10 Rasmus Lilja Introduktionsutbildning inom NyA Genomgång av våra roller, ansvarsområden och arbetsuppgifter (med utgångspunkt i beskrivning av roller). Rasmus presenterar verksamhetsförvaltningen. Reijo presenterar teknikförvaltningen. 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. Jag tänkte att jag skulle ta det från grunden och börja med att presentera några nyckelroller inom organisationen kring NyA för att ni ska få en bild av hur det fungerar. Våra roller

Våra roller – vad gör en produktägare? Ansvarar för utvecklingen inom sitt område Har mandat att bestämma vad som utvecklas när (baserat på verksamhetens behov) Har mandat att säga nej! Ensam ”uppdragsgivare” åt ett eller flera utvecklingsteam Tar fram planer på kort och lång sikt Samlar aktivt in krav och önskemål från verksamheten Kommunicerar med team och förvaltningsledning Produktägare En produktägare ansvarar för det som utvecklas inom sitt område. Ansvaret innebär i stort att bedöma och besluta att rätt saker utvecklas i rätt tid och på rätt sätt för att uppnå mesta möjliga verksamhetsnytta. Produktägaren har mandat att bestämma vad som ska utvecklas och i vilken ordning baserat på verksamhetens behov. Mandatet innebär även att ta beslut om vad som inte ska utvecklas. I produktägarrollen ingår också att värdera mellan nyutveckling och tekniskt underhåll. Det innebär att produktägaren är ensam ”uppdragsgivare” åt ett (eller flera) utvecklingsteam. Ingen annan än produktägaren får ge utvecklarna i uppdrag att arbeta utifrån andra krav än de som produktägaren angett som prioriterade. Produktägaren har även det slutgiltiga mandatet att godkänna det som utvecklats. I produktägarens roll ligger även att vara visionär och leda utvecklingen inom sitt område. Det innebär att ta fram mål och visioner som ligger samklang med resten av systemet på kort och på längre sikt. Att vara produktägare är en kommunikativ roll. En viktig del i produktägarens arbetsuppgifter är att kontinuerligt hålla kontakten med verksamheten och aktivt samla in krav och önskemål. Det är även produktägarens ansvar att verksamhetens behov kommuniceras till utvecklingsteamen tillräckligt bra för att de ska förstå dem. Det är även viktigt att produktägaren har en god kommunikation med förvaltningsledningen/produktledningen. Typiska arbetsuppgifter för en produktägare är att: Samla in krav och önskemål från verksamheten Prioritera vilka åtgärder som ger mest nytta åt verksamheten Säga nej (bestämma vad som inte ska utvecklas) Hålla kontakt med verksamheten Omvärldsbevakning Ta fram mål på kortare sikt (för exempelvis sprintar och inkrement) Ta fram mål på längre sikt (roadmap) Följa upp målen Acceptera resultat från utvecklingen Definiera övergripande User Stories Produktägaren bestämmer VAD som ska utvecklas, stort ansvar och stora mandat

Våra roller – vad gör en krav-/verksamhetsanalytiker? Huvudsaklig uppgift att utreda verksamhetens behov Formulera, detaljera och dokumentera krav på ett sätt som gör dem användbara Granska lösningsförslag från utvecklingsteamen Krav-/verksamhetsanalytiker En krav-/verksamhetsanalytiker har som huvudsaklig uppgift att utreda verksamhetens behov. En viktig del i arbetet är att och samla in krav på både övergripande och detaljerad nivå samt att formulera och dokumentera kraven på ett sätt som gör dem tydliga och användbara. I en krav-/verksamhetsanalytikers arbetsuppgifter ingår bland annat att leda referensgrupper, göra processkartläggningar, sammanställa och dokumentera krav samt granska förslag från utvecklingsteamen på hur olika lösningar kan se ut och fungera. I krav-/verksamhetsanalytikerns uppgifter ingår även att hjälpa användare i samband med att ny eller förbättrad funktion sätts i produktion. Typiska arbetsuppgifter för en krav-/verksamhetsanalytiker är att: Utreda behov Kravfångst Reda ut oklarheter på detaljnivå Leda och arbeta med referensgrupper Stödjer/hjälper användare och verksamhet efter produktionssättning på detaljnivå Göra processkartläggningar Kravledning Dokumentera kraven Granska lösningsförslag (från utvecklingsteamen) Produktägaren har fokus på utvecklingen inom sitt ansvarsområde medan krav/- verksamhetsanalytikern har fokus på att samla in kraven.

Våra roller – vad gör ett utvecklingsteam? Ta fram förslag, designar och utvecklar lösningar Övergripande förståelse av verksamhetens och dess behov Ansvarar för att ”ta reda på mer” om det behövs Testar sina lösningar Teknisk kompetens för exempelvis arkitektur, ramverk, plattformar etc. God förståelse för delsystemets roll i helheten Om produktägaren bestämmer vad som ska utvecklas så är det teamets ansvar för hur det utvecklas. Står för själva lösningen som sådan. Är självorganiserande. Teamets uppgifter Utvinna och analysera (detaljerade) krav Kravfångstmetoder: intervjuer, observationer, prototyping Analysmetoder: modellering, workshoppande, prototyping mm Designa lösning Utveckla lösning Testa lösning Övrigt inom utveckling: arkitektur, ramverk, plattformar mm Kompetensprofil för teamet Övergripande förståelse av verksamheten och dess behov/problem God förståelse av syfte och användning av delsystemet och delsystemets roll i helheten (hela systemet, hela verksamheten) Djup teknisk kunskap om den tekniska lösningen i systemet i allmänhet och delsystemet i synnerhet

Våra roller – vad gör en verksamhetsspecialist? Verksamhetsrepresentant Stödjer produktägare, kravanalytiker och utvecklingsteam genom hela krav- och utvecklingscykeln Ser lite olika ut inom de olika områdena – ibland fasta personer ibland temporära referensgrupper Verksamhetsspecialister utifrån behov och utvecklingsområde För att kvalitetssäkra arbetet inom förvaltningen har vi strävat efter att komplettera de agila teamen med representanter från lärosäten. Syftet är att stödja produktägare och utvecklingsteam genom hela krav- och utvecklingscykeln. Då behoven skiftar mellan spår och över tid så har det blivit olika lösningar inom respektive område. Vi har tecknat avtal med några lärosäten för de spår som har behov av fasta resurser, medan andra spår har haft mer tillfälliga och skiftande verksamhetsrepresentanter. Det var våra roller – frågor? Upplever ni att något som är oklart när det gäller relationerna mellan rollerna?

Våra roller – vad gör en förvaltningsledare på verksamhetssidan? Styrande och samordnande roll – leder arbetet inom förvaltningsobjektet Håller ett helhetsperspektiv och ser till att alla strävar mot samma mål Organisation samt gemensamma rutiner och arbetssätt Initierar gemensamma aktiviteter Håller kontakten med verksamheten via bland annat förvaltningsråd Budgetering, resursplanering och bemanning Rapportering och uppföljning Samarbetar tätt med förvaltningsledaren (IT) De roller som ligger närmast utvecklingen är produktägare, krav-verksamhetsanalytiker samt utvecklingsteamen så klart. Till detta finns även en förvaltningsledning som i grovt är uppdelad på två roller: Förvaltningsledare på verksamhetssidan Förvaltningsledare IT Två sidor av samma mynt där den ena förvaltningsledaren håller ett verksamhetsperspektiv med användarna i centrum och där den andra håller ett mer teknikorienterat perspektiv med själva systemet som sådant i centrum. Förvaltningsledare (verksamhet) Förvaltningsledaren har en styrande och samordnande roll. Förvaltningsledaren håller ett helhetsperspektiv  och jobbar för att hela organisationen kring förvaltningsobjektet strävar mot gemensamma mål .   I förvaltningsledarens uppgifter ingår att ta fram planer på kort och lång sikt och skapa så goda förutsättningar som möjligt för att organisationen ska nå de uppsatta målen. Förutom delar som bemanning och budgetering av förvaltningsorganisationen arbetar förvaltningsledaren ständigt för att systemet ska vara användbart och motsvara användarnas behov i stort. Förutom att se till att systemet utvecklas i rätt riktning innebär även att se till att det finns rutiner för att hålla exempelvis verksamhetsprocesser och dokumentation om systemet korrekt och uppdaterat. Kommunikation är en central del av förvaltningsledarrollen. I sin samordnande roll kommunicerar förvaltningsledaren med hela förvaltnings- och utvecklingsorganisationen. I sin rapporterande och uppföljande roll kommunicerar förvaltningsledaren med systemägare, intressenter och uppdragsgivare. Förvaltningsledaren håller kontakten med verksamheten med hjälp av förvaltningsråd eller andra typer av referensgrupper för att kontinuerligt få in synpunkter från kunder och användare av systemet. Förvaltningsledare (verksamhet) och Förvaltningsledningen IT är samarbetspartners. De har ett gemensamt ansvar inför styrgrupp och samarbetar tätt kring frågor som förvaltningsplan, statusrapportering, koordinering av aktiviteter samt uppföljningar. Typiska arbetsuppgifter för en förvaltningsledare på verksamhetssidan är att Leda arbetet inom förvaltningsobjektet Initiera och samordna aktiviteter Leda förvaltnings-ledningens möten Sammankalla och leda förvaltningsråd Sätta upp mål för utveckling och förvaltning Ta fram långsiktig förvaltningsstrategi Ta fram en förvaltningsplan Budgetering och uppföljning Resursplanering Bemanning Verkställa mål i förvaltningsplanen Skapa direktiv för utveckling och förvaltning Beställare. Ställa krav på projekt ur ett förvaltningsperspektiv Följa upp förvaltningsplanen Budgetering och att följa upp budget Ta fram underlag till årsredovisning och uppföljning Statusrapportering Avvikelserapportering Hantera avvikelser ur ett verksamhetsperspektiv Omvärldsbevaka ur ett verksamhetsperspektiv Ta fram förvaltningsdokumentation Samordna med angränsande system Representera förvaltningsobjektet för intressenter Tolka och jämka intressenters behov Ansvarsområden: Verkställa förvaltningsplanens mål inom givna ramar på ett kostnadseffektivt sätt. Samordning med teknisk förvaltningsledare. Upprätta förvaltningsplan och budget. Ekonomisk uppföljning för hela systemförvaltningsobjektet. Avvikelserapportera till Systemägaren. Utveckling av processer för verksamhetsförvaltning. Samordning med angränsande processer. Organisera verksamhetsgrupper, delta i rekrytering av verksamhetspersoner till förvaltningsorganisation. Tjänsteutveckling, metodutveckling för förvaltningsarbete. Bevaka användarnyttan. Omvärldsbevakning, planera och arbeta med framförhållning. Ordförande och sammankallande till förvaltningsgruppsmöten. Ordförande och sammankallande till förvaltningsrådsmöten. Övergripande ansvarig för att prioriteringar av förvaltningåtgärder genomförs enligt principer och mål fastsställda i förvaltningsstrategi och förvaltningsplan Övergripande ansvarig för att systemförändringar bereds ur ett verksamhetsperspektiv Genomföra beställningar till den tekniska förvaltningsorganisationen. Löpande följa upp att utvecklingen genomförs i enlighet med fastställd förvaltningsplan. Helhetsperspektiv för verksamhetsrutiner och utvecklingen av dessa. Ansvara för att ta reda på verksamhetens krav för informationssäkerhet. Att verka för att samordningsvinster ur verksamhetsaspekt uppnås mellan Ladok- och NyA-systemet. Besluta om förvaltningsåtgärder och prioriteringar inom ramen för förvaltningsplanen.

Våra roller – vad gör en teknisk förvaltningsledare? Leder den tekniska förvaltningen Ansvarar för att systemet fungerar på kort och lång sikt Arbete med den tekniska arkitekturen på strategisk nivå Samordnar interna och externa leverantörer (ITS) Uppföljning av IT-kostnader Samarbetar tätt med förvaltningsledaren verksamhet Lämna över till Reijo! Förvaltningsledaren IT leder den tekniska förvaltningen och har ett ansvar för att systemet och de tekniska komponenterna inom förvaltningsobjektet fungerar på både kort och lång sikt. Är förvaltningsledaren verksamhets samarbetspartner (teknik och verksamhet – två sidor av samma mynt)   Förutom att kunna leverera ett fungerande system inkluderar ansvaret även tekniska samband och tredjepartsprodukter. Förvaltningsledaren IT har det övergripande ansvaret för produktionssättningar, tar fram incidentplaner och ser till att externa leverantörer styrs med kontrakt. Förvaltningsledaren IT strävar hela tiden efter att organisationen ska ha en förmåga att leverera ett fungerande system. Rollen innebär att säkerställa och beställa kompetens för utveckling men även med att arbeta med den tekniska arkitekturen på strategisk nivå. Förvaltningsledningen IT och Förvaltningsledare (verksamhet) är samarbetspartners. De har ett gemensamt ansvar inför styrgrupp och samarbetar tätt kring frågor som förvaltningsplan, statusrapportering, koordinering av aktiviteter samt uppföljningar. Typiska arbetsuppgifter för Förvaltningsledaren IT är att: Leda teknikförvaltningen Agera vid incidenter Delta på förvaltningsledningsmöten Prioritera och besluta inom förvaltningsplanen Samordna interna och externa leverantörer Följa upp utfallet av IT-kostnader Rapportera budgetutfall Föredra ärenden Koordinera och administrera aktiviteter samt starta upp nya Ställa krav på projekt ur ett förvaltningsperspektiv Underlag för fakturering till kunder Omvärldsbevaka ur ett tekniskt perspektiv Samordna uppdrag och aktiviteter med andra objekt och projekt inom samma program Ansvarsområden: Samordning med verksamhetens systemansvarig. Förvaltningsobjektets funktionalitet ur tekniskt helhetsperspektiv. Förvaltningsobjektets förvaltningsbarhet. Lämna underlag till förvaltningsplan och budget. Utveckling av den tekniska förvaltningens tjänster och dess processer. Omvärldsbevakning och metodutveckling för tekniskt förvaltningsarbete. Samordning med angränsande processer, system och projekt. Lämna underlag för beställning till verksamhetens förvaltningsorganisation. Genomföra beställningar från verksamhetens förvaltningsorganisation. Följa upp det tekniska förvaltningsarbetet, kvalitetssäkring, dokumentation och teknisk test. Kostnadseffektivitet i det tekniska förvaltningsarbetet. Teknikperspektivet i förvaltningsgruppen. Att koordinera driften av systemet med vidareutveckling. Inrätta och bemanna tekniska berednings- och arbetsgrupper. Utforma avtalsförslag med leverantörer av förvaltningstjänster och bidra med underlag till avtal om drifttjänster. Uppföljning och samordning av leverantörernas tjänster. Verka för att samordningsvinster uppnås mellan Ladok- och NyA-systemet avseende gemensamma tekniklösningar där så är möjligt. Ansvara för att kvalitetssäkringsåtgärder genomförs.

Teknisk förvaltningsledning 2017-03-10 Reijo Soréus Teknisk förvaltningsledning Rollen och ansvaret

Beskrivning Leder tillsammans med FL-V (Anders) förvaltningen av systemet Säkrar resurser Uppföljning och kvalitetssäkring Ansvarar för objektets långsiktiga förvaltningsbarhet

Kontaktytor Förvaltningsgruppen Inåt, träffas veckovis Uppdragsansvarig (UA) på ITS (Patrik Jonasson) Uppföljning av uppdraget veckovis Scrum Masters Uppföljning av kvalitetssäkring och test Förvaltningsretrospektiv Fyra gånger per år med förvaltningsgruppen, UA och en ScM Spåret för arkitektur och teknisk strategi (TEK) Produktägare för området

Artefakter Säkerhetspolicy för NyA Riktlinjer för kvalitetssäkring och test IT-strategi Uppdragsöverenskommelse med ITS

Grupper och råd

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. Nämn också den systemstartegiska gruppen. Helt nystartad. SA-chefer? Leds av Zäta och Mauritz på Ladok3.

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.

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. 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.

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ägarena 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

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.

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

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. 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

Så här jobbar vi tillsammans! 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.

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. 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. 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

Genomgång av paketmallen på Confluence Se Confluence >> CONFLUENCE: INTRODUKTIONSUTBILDNINGEN – GÅ IGENOM PAKETMALLEN HÄR VISA DOKUMENTATION FRÅN BRP. Plan, mål, risker etc GÅ IGENOM JIRA STRUCTURE

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!

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!

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. Planerar vi in för mycket? 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.