Fokus for neste sprint
- SM inviterer fleire interessenter på Daily Scrum, som optional.
- Teamet legg inn alt dei oppdager av teknisk gjeld i Jira som Technical Debt.
Sak 1: Oppsummering av sprinten
Korleis gjekk det? Kort runde.
- Vart torpedert av Unplanned. Mykje som dukka opp, 34% scope change, som er endå meir enn forrige sprint, på 22% scope change. Ser ikkje kva vi kunne gjort med dei.
- Vi treng å jobbe med QA.
- Var ein bra sprint, om ein såg vekk frå alt som var unplanned.
- Var flinke til å oppdatere Jira fortløpande.
- Nokre stories var uklare, email forward for UiA.
Sak 2: Forrige fokusområder
Frå forrige retrospective. Har vi greidd det vi ville fokusere på?
- Oppmøte på Daily Scrum: Fungerer bedre enn forrige gang. Vi er fornøgde og gjer ingenting med det.
- Best practive på Git workflow: sgs kaller inn til møte
- Team rydder i gamle brancher: Ser bedre ut, men gjenstår litt. Alle må slette brancher når dei mergast. jsama tek seg av branchen exchange-fixup-master
- Punktliste for cere-utv04: Ser greit ut. fhl og jsama snakker med tvl om automatisk overføring av cache/ (dumps/), og tar over utviklingsmaskinene. Elles venter vi på FS-tilgang, elles ok.
Sak 3: Lean Coffee Retrospective
Nådde ikkje dette punktet.
Snakka om at det er mykje hummer og kanari i Cerebrum-koden. Anbefaler alle å legge inn CRB-saker i Jira av typen Technical Debt.
Sak 4: Smidig 2015
sgs, fhl, jbr og jokim oppsummerte kva dei fekk med seg frå Smidig-konferansen:
Tema for konferansen var å vere smidig, versus å gjere smidig. Agile/smidig er eit tankesett, definert av verdiar, styrd av prinsipper, som til slutt er manifistert i praksis og verktøy. Verktøya kan byttast ut, det viktige er tankesettet!
Idear og forslag som vi kan tenke på:
- Invitere mange interessentar på Daily Scrum. Alle som også vert invitert på Sprint Review? Krever at vi har streng kustus på kva vi prater om. Ingen dialog.
- Vi prøver ut dette denne sprinten.
- Tech Review: Skille ut eigne reviews for det tekniske, internt for utviklarane.
- Forslag om sjekkpunkt på Sprint Planning: Er det behov for nokre tech stories i denne sprinten?
- Lågare fokusfaktor:
- Sprint Planning:
- Forarbeid før sprint planning, så ein set seg inn i koden først, så kan ein diskutere i 10 min og ikkje ein time på sprint planning.
- Par-programmering:
- La to personar jobbe med samme skjermen, samtidig. Fungerer for å dele kunnskap, og ikkje minst å få ein felles forståelse for kodestandard, mål, overordna og felles språk.
- Bra verktøy for å komme i bedre retning
- Sjekkpunkt til Sprint Planning: Er dett noko som bør gjerast med par-programmering?
Anbefalte videoar frå Smidig2015:
- 10 suksesskriterier for en moderne systemutviklingsorganisasjon - Fellestrekk for å lykkes.
- Du lærer ikke av erfaring - Forskning som viser at det hjelper å diskutere gjennom det som har blitt gjort.
- How to Volkswagen your IT-project - 5 ting du ikkje bør gjere.
- NoEstimates - Bruk statistikk på tidlegare sprintar i staden for å estimere frå hauet. Vi diskuterte denne litt, vil ikkje nødvendigvis funke for vårt team grunna stor variasjon i sprintar og produkt.
- Beretninger fra en estimatfri virkelighet - NoEstimates i praksis.
- Safe Lean Agile Devops Scrumban - SLADOS - Morsom parodi!
- Post Lean and higher organization - ikkje dekkande for oss, men inspirerande (såg ikkje ut til å vere lagt ut endå).
Diskuterte Sprint Planning og estimering. Kom opp tankar om korleis gjere Sprint Planning kortare, med meir forbereding for å gjere klar stories før planleggingsmøtet.
- Dele opp Sprint Planning i to, der første del er gruppearbeid. Vi kan diskutere dette i starten av førstkomande Sprint Planning. Det er uansett diskusjonen som er viktigast å få ut av planleggingsmøtet, og vi treng då at alle er samla.
- Før Sprint Planning: Ein annan i teamet ser over andre sine user stories, for å sikre at alt er med i storyen.
I etterkant av møtet, frå Hans Kristian:
[...] svarer Mike Cohn på et lignende spørsmål. Legg spesielt merke til:
...the two purposes of having a sprint planning meeting:
* Collaboratively selecting a set of product backlog items to work on
* Having a rough idea of the work to be done to deliver those items
Jeg tenker relativt ofte at vi legger lista litt for høyt i å få riktige
estimater, og at vi bla. derfor graver oss litt for dypt inn i tekniske
detaljer og løsningsrom. Det er mye opptil dere om dere vil ha det slik
eller ikke, men for min del er det helt greit om sprint-planningen blir
mindre detaljert og mer smidig, på bekostning av påliteligheten i
estimater. Diskusjonene er mye viktigere enn estimatene.