Big Room PlanningNyA Scaling Scrum the SAFe way…

2016-03-22Reijo Soréus

Problem och processAktuella problem att svara på

• Hubblandet Dålig information om valideringsändring, bristande kommunikation! Information om ? Nådde inte ut trots föravisering Problem med validering av studiestödsattributet fixas i 04

Problem

Läget i NyA

• Utvecklingsprojektet 1999-2005 Initial budet 75 MSEK och planerad leverans dec 2003 Levererades 2005 till en kostnad om 186 MSEK Totalt 337 400 timmars arbete Omfattande restlista

• Total budget 2016 för förvaltning ca MSEK 63

• Över 75 000 utvecklartimmar

Förvaltningen i siffror

• Nyss genomfört övergången till Basefarm Inga större problem trots allmänna uppgraderingar

• Ladok3-anpassandet kräver fortfarande mycket resurser

På bordet

1,88

3,33

2,222,57

2,33

4,37

2,19

1,31

1,75

1,311,51

1,71

0,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

8,00

9,00

2014_02 2014_05 2014_09 2014_11 2015_02 2015_03 2015_04 2015_05 2015_06 2015_09 2015_10 2015_11

Antal felrapporter hittade i produktion per 1000h levererade timmar uppdelat per leverans

Low

Minor

Major

Critical

Blocker

Glidandemedelvärde

Avskaffad acceptanstest

Nyckelbytet

Produktionssupport (ackumulerat årsvis)

0

500

1 000

1 500

2 000

2 500

3 000

Januari Februari Mars April Maj Juni Juli Augusti September Oktober November December

2012

2013

2014

2015

2016

Supportbehovet har sjunkit med över 500 timmar

• Övergången till agil utveckling enligt Scrum i stort sett genomförd Efterföljande acceptanstest avskaffades 2015

• Sex team (inklusive TEK) med 4-8 utvecklare

• Sex produktägare för verksamhetsområden Produktionsstyrning Handläggning och Behörighetsmodeller Institutionsanvändare Sökande

• Teamen jobbar i huvudsak tillsammans med var sin produktägare

• Stora projekt kan få sin egen produktägare Personuppgiftstjänsten Separat antagning av avgiftsskyldiga sökande (SEPA)

• Kvaliteten håller

NyA 2016

• Fortsatt agilisering Siktar på Continuous Integration Continuous Deploy inte på kartan. Ännu.

• Förbättra och förtydliga leveransplaneringen Vi vill bli bättre på att presentera kommande funktionalitet

• Bättre samordning mellan spåren Minska tendenser till silos Parallellt med arkitekturförbättringar (minskade beroenden)

• Prioritering på helhetsnivå Vad är viktigast för NyA?

What’s next?

• Continuous Integration Ny branchningsfilosofi – mindre och oftare Fortsatt testautomatisering, minimera Arquillian Git har ersatt ClearCase Börjat prova Docker Se över CM-processen och driftmiljöerna

• Se över dokumentationen Vad ska dokumenteras och hur? Infört Confluence

• Estimering

• Testa SAFe (Scaled Agile Framework) Prova delar av ramverket Big Room Planning

Fortsatt agilisering

Olika typer av utveckling

Underhåll och mindre ändringar

Refaktorisering av teknisk skuld

Vidareutveckling, ny funktionalitet

Formalia 10%

Olika delar i olika skick - prioritering

Underhåll

Teknisk skuld

Vidareutveckl

ing

Funktion

Underhåll

Teknisk skuld

Vidareutveckl

ing

Kvalitet

• Hushålla med resurser – hitta de bästa projekten

• Tänk system

• Säkra variabilitet så länge som möjligt, håll alternativ öppna

• Bygg inkrementellt, snabba lärcykler

• Basera milstolpar på utvärdering av vad som fungerar

• Synliggör och begränsa WIP

• Kadens och synkronisering på objektnivå

• Mål och motivation

• Centralisera strategiska beslut, decentralisera övriga

SAFe grundprinciper

SAFe

• Varför?̶ Prioritering på objektnivå̶ Problem vid interna beroenden̶ Ledningsroller och behov

• Varför inte?̶ Resursintensivt̶ Kräver metodkonvergering̶ Lockar till vattenfallstänk

SAFe – en agil dinosaurie? …eller bara en verktygslåda till?

SAFe objekt

Våra planeringsbegrepp

Utredning

Nuvarande process Önskad process

Spår Satsning

Sökande Kommunikation med sökande

Sökande Tillgänglighet på antagning.se

Sökande Reservantagning

Sökande Ny kurssök och filtrering

Institution Reservantagning

Produktionsstyrning Meddelandelistor

Produktionsstyrning Separat antagning av avgiftsskyldiga sökande

Handläggning Modernisering och förbättring

Handläggning Förstagranskning

Teknik och arkitektur Ny statistiklösning

Satsningar 2016

+ Ladok3-anpassningar…

Inkrement och sprintar

Spri

nt

Spri

nt

Spri

nt

Spri

nt

Spri

nt

Inkrement

Inkrementmål

Pla

ne

rin

g

Spri

nt

Spri

nt

Spri

nt

Spri

nt

Spri

nt

Inkrement

InkrementmålP

lan

erin

g

Spri

nt

Spri

nt

Spri

nt

Spri

nt

Spri

nt

Inkrement

Inkrementmål

Pla

ne

rin

g

Spri

nt

Spri

nt

Spri

nt

Spri

nt

Spri

nt

Inkrement

Inkrementmål

Förvaltningsplan, budget…

Förvaltningsmål

…eller mer specifikt

• Handläggning SEPA: Meritvärdering av sena ansökningar SEPA: Städa logik Stretch: Mallar för tjänsteanteckningar

• Institutionsanvändare Första version av ny handläggning på webb med pilot i produktion Hämta t.o.m.-datum för tidsbegränsat uppehållstillstånd Anmälnings- och studieavgift för separat antagna Utredningar av utdata, hantering anmälningsalternativ, sök person…

• Produktionsstyrning Ladok3-anpassningar Renovering av AF109 ( Koncept för urvalsmodeller, inklusive modellering av sena

Mål för inkrement 1 (några utplock)

Teamsamverkan

PAGE 22

APO

Product Backlog

Potienially Shippable Increment

Spri

nt

Rev

iew

Spri

nt

Ret

rosp

ecti

ve

Join

t R

etro

spec

tive

Sprint Plannng Part 1

Sprint Plannng Part 2

Sprint Backlog Product Backlog Refinement (5-10% of

Sprint)

2-4 w Sprint

1 dDaily Scrum

› Collaboration– Joint Sprint Planning part 1– Participates in Joint Product Backlog Refinement– Joint Sprint Reviews– Joint Retrospectives at selected intervals– Coordination between teams handled by teams, e.g. Joint Design

Workshops and Joint Testing when needed, Scrum of Scrums– Coordination towards external parts handled by selected

representative– Co-located if possible

Anatomy

POProduct Backlog

Refinement

XFTScM

PO: Product OwnerAPO: Area Product OwnerScM: Scrum MasterXFT: Cross-functional Team

Big Room Planning mars 2016

67 personer!

• Gemensam planering där alla kan och ska bidra

• Identifiera beroenden och dela på arbete

• Prioritera på objektnivå

• Inte en detaljplanering!

• Planer är till för att förändras…

Varför Big Room Planning?

Program

Presentation av paket för inkrementet

Teknik, arkitektur och metod

Introduktion till planeringsprocessen

Team

se

ssio

ner

Team

se

ssio

ner

Team

se

ssio

ner

Team

se

ssio

ner

Team

se

ssio

ner

Team

se

ssio

ner

Team

se

ssio

ner

Genomgång av planer

Utvärdering och prioritering

Diskussion kring justering

Genomgång av planer

Riskanalys

Paus

Riskanalys

Genomförbarhet, åtgärder

Feedback, utvärdering, summering

Dag 1 Dag 2

Spårets planering

Beroenden

Riskhantering (ROAM)

Vi har en lösning

Shithappens…

Någon tar ansvaret för att hantera risken

Risken kan minskas eller

konsekvenserna begränsas

Risker i NyA 2016 PI1

• Omplanering – SEPA Spåret hinner inte få färdigt funktionaliteten i tid till i november Behöver stöd från andra spår, prioritering för objektet Visade på behovet av estimat på hög nivå och nedbrytning

• Gemensam översikt och koll på målen

• Uppföljning på paketnivå Levererbar (nyttig) funktionalitet Grund för införandeplanering

• Confluence Wiki för planering och strukturering Informationskälla för hela förvaltningen Hanterar satsningar och paket

Resultat