• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
En scrum masters roll i agilt förändringsarbete | Cecilia Andrén | LTG-14
 

En scrum masters roll i agilt förändringsarbete | Cecilia Andrén | LTG-14

on

  • 759 views

 

Statistics

Views

Total Views
759
Views on SlideShare
612
Embed Views
147

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 147

http://leantribe.org 147

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 3 döttrar13 år på Ericsson36 timmar tycker jag det borde vara per dygn – vill mer än jag hinner med
  • För drygt ett år sedan började jag på Ericsson på Lindholmen och blev anställd som scrum master. Jag har sedan 1999 jobbat på Ericsson i Lund och har haft många positioner där jag drivit förändringsarbete i kombination med teknik. Nu skulle jag få chansen att arbeta med scrum – och ha en stor möjlighet att påverka hur vi arbetar.
  • För ett år sedan var mitt team redan igång men de hade ingen scrum master. De hade kört scrum som ett pilotprojekt först sedan sommaren 2011 och blev av med sin scrum master på vägen. De jobbade enligt scrum principer med möten, backlog mm men jag upplevde inte att de var agila. Där ser jag att en scrum master har en stor roll att spela. Det krävs vilja, tro, engagemang och hårt arbete för att få förändringar att ske. Vi måste sträva mot ett läge där vi har samsyn i organisationen och ett arbetssätt som sitter i väggarna.
  • Som scrum master ska man serva och leda organisationen, produkt ägaren och utvecklingsteamet framåt i ständig förbättring. Alla tre delarna är viktiga att arbeta med. Jag tänkte nu ge era några exempel på hinder som vi stött på i vår agila utveckling och vad vi gjort för att komma framåt.
  • En sak vi hade problem med under våren 2012 var att vi aldrig gick i mål med våra sprintar. Varför blev det så frågade jag mig?
  • Vad vi gjorde var att då göra en övning i teamet för att skapa förståelse för varför det är viktigt att uppnå sprint målen.Först – varför uppfyller vi aldrig målen? Exempel på detta var då: dålig planering, underestimerar arbetet, det är inte så viktigt – viktigare med slutmålet mm. Det fanns många skäl och vissa saker kunde man åtgärda utan enorma insatser.
  • Nästa steg var då att se vad vi tjänar på att sätta upp realistiska sprint mål. Exempel där blev: nöjda med oss själva när vi klarat målen, kan göra en bättre prognos, inte behöva stressa en massa,förtroende från kunder på att leverera i tid mm.
  • Detta hjälpte! Nu lyckas vi i de flesta fall bra med sprintmålen.
  • Teamen tycker det är svårt att kunna allt! Vi har som mål att vara korsfunktionella. Vi vill kunna ta på oss breda uppgifter och inte vara så sårbara om någon är sjuk. Vi vill inte längre ha experter som är den enda som kan lösa ett problem.Inledningsvis hade vissa personer alltid samma uppgift. Det fanns ett motstånd mot att bredda sig – svårt besvärligt, jag vill ha min modul – praktiskt. Går snabbare om jag gör det själv.Vi har haft denna fråga uppe på ett flertal retrospective – vad kan vi göra för att klara av att kunna så mkt.Därför har jag fått in i teamets mindset : enligt listanDet kräver dock aktivt att man tar upp dessa frågor ett antal gånger. Det är lätt för teamen att få återfall.
  • Vi har även haft mycket jobb med att ändra tankesättet att vi ska göra det perfekt, det lilla extra. Förgylla saker om att kunden kanske vill ha mer.Där har vi som mål att tänka iterativt – precis som man ska enlgit scrum. Vi ska göra det vi vet att kunden vill ha och inte gå utanför gränserna för mycket. Våra ingenjörer är dock vana vid att ha en produkt som ska levereras om1,5 år och då måste man tänka lite mer framåt eftersom kraven kanske utökats. Så ska vi inte göra nu. Vi har nu utökar dialogen med produktägare och kunden.Vi skriver tydligare user stories med kundvärde. Innan kunde våra user stories vara uppdelade i bitar, tex implementera koden var en story och nästa skriv testfallet. Det blev inte bra. Vertikala stories som kan ge kundvärde är vad vi satsar på. Tydliga acceptanskriterier för alla våra user stories. Vad innebär det att vi är klara. Det är vad vi ska göra i första hand.Men ibland så får jag ta på poliskläderna – vem är det egentligen som betalar för detta??? Jag med tre småbarn har haft en hel del VAB. Då ser jag att det är lätt att få återfall för teamen när de är nya inom agilt. Ständig upprepning och diskussion krävs för att få in det som grundvärderingar.
  • Mycket jobb blir inom teamet. Jag har märkt att många scrum masters ser OPO:n som någon utanför teamet och vågar inte ställa krav på dem. Det är en viktig del som inte får glömmas.När jag började hade vi många stories utan kundvärde – det var delar av funktionalitet – implementerat kodvar en story. Testat kod en ehlt annan.Vi hade inga tydliga acceptanskriterier – när var vi klara. Svårt att se värdet av varför vi skulle bli klara inom en sprint. Kunden kunde ju ändå inte använda resultatet.Vi skrev en hel del stories själv som OPO:n inte riktigt kunde stå för. VAD HAR VI GJORTOPOn tar ansvar för backloggen och har koll på sina stories. Vi vär att vara väldigt hårda på att formulera stories på ”In order to ...” för då blir det tydligt varför vi gör något och åt vem. Enklare att säkra att vi gör rätt saker då. Tydliga AC, ibland format ”I can do this with that” som vi kan bocka av att vi verkligen gjort det vi skulle.OPO:n godkänner inte en story om in AC är uppfyllda. När vi hade otydliga AC kunde det ibland ske att vi fick godkänt trots att det fanns småsaker utestående. Med tydliga AC så blir detta problem mindre.Vi är transparanta och visar vart vi är på väg, uppdelning i sprintar i backloggen i närtid. Bra förkunden men även för andra team eftersom vi är många i samma produkt. Dessa saker har gjort att vi mer förstår varför vi gör saker och gör det mer motiverande att utföra arbetet. Dessutom tydligt när vi är klara. Enklare att göra en bra sprintplan då.
  • Den svåraste frågan har vi inte riktigt löst. Om man vill ändra arbetsätt så att det påverkar flera team. Tex skulle vi införa en CI motor i vårt kravområde och tryckte ut den och körde på med vägvälten för att få alla att börja använad den. Resultatet var inte uppmuntrande. Det tog enormt lång tid. Teamen var inte intresserade – de såg inte vinsterna. Vad jag skulle önskat är att vi hade lanserat ett koncept, hade förankrat och förfinat med de andra teamen. Att vi hade gjort mycket reklam och hjälpt till vid sjösättningen. För att få detta att fungera så behövs det någon som aktivit driver förändringen så att alla team frivilligt gick med och kände att de kunde påverka. Med delaktighet och personer som vill så kan man förändra mycket! Multisite svårt.
  • Det sägs att tiden ändrar saker men man måste faktiskt ändra dem själv.Därför behöver ett scrum team sin scrum master speciellt i början – eller någon som vill driva förändring. Vilja, engagemang, tro och hårt arbete krävs för att verkligen få organisationen att bli agil.

En scrum masters roll i agilt förändringsarbete | Cecilia Andrén | LTG-14 En scrum masters roll i agilt förändringsarbete | Cecilia Andrén | LTG-14 Presentation Transcript

  • En scrum masters roll i agilt förändringsarbete
  • Vem är jag?
  • Vad är min roll?• Scrum master Ericsson AB
  • NYTTARBETSÄTT ENGAGEMANG VILJA TRO SAMSYNARBETE
  • Tre områden att serva Produkt- ägare Utvecklings-Organisation team
  • Team: Vi blev inte klara i sprintarna?Sprint 1 Sprint 3Sprint 2 Sprint 4
  • Varför blir vi aldrig klara?
  • Vad vinner vi på att bli klara?
  • Varför + vinster = succe!•Skapa förståelse –Varför klarade vi inte målen => åtgärder –vad vinner vi
  • Team: Svårt att kunna allt i en komplex miljö• Mål: – Vara korsfunktionella i teamet – mindre sårbara – Undvika enmansshow• Få in i teamets ”mindset”: – Rotera uppgifter – Skapa wikisidor med stöd – Par-programmera för kunskapsspridning – Säkra bra CI maskin, testfall – våga göra förändringar. Vi kör automatiskt fulla tester, lint, mem check innan leverans. – Se värdet av att kunna bidra på många plan
  • Förgyllning, perfektionism• Mål: Tänka iterativt, göra det vi vet att kunden vill ha.• Problem: Ingenjörer vill göra hela lösningen – det lilla extra som kanske kan vara bra.• Lösning: – Dialog med produktägare och kund – Tydliga user stories med kundvärde – Tydliga acceptans kriterier VEM ÄR DET för vad som är klart EGENTLIGEN SOM BETALAR FÖR DETTA
  • PO: Backlog, user story format, acceptanskriteria• I början: Glöm inte – User stories utan fullt kundvärde coacha – Inga tydliga acceptanskriteria PO:n• Lösningar: – Formulera allt på "As a <role>, I want <goal/desire> so that <benefit>" – Tydliga AC, ibland ”I can xxx with yyy” – Godkänn endast om klart -----------13w09--------- As a user I want aaa As a user I want bbb – Transparans på vägen framåt As a user I want ccc ----------- 13w12-------- As a user I want ddd As a user I want eee As a user I want fff
  • Ändra WoW för flera team”• Exempel: Inför CI motor i vårt område (15 team)• Utfall: Enormt långsamt – Forcerade – Team ville ej vara med – varför???• Vad borde vi gjort? 1. Lansera koncept 2. Förankrat och förfinat idé med andra ScM och team 3. Gjort reklam och supportat deployment DELAKTIGHET – VILJA => möjlighet att förändra stort
  • Det sägs att tiden ändrar sakermen man måste faktiskt ändradem själv.