Posts Tagged ‘vattenfall’

h1

Projektledningsaspekter i Scrum?

torsdag, 15 april, 2010

När jag är ute och föreläser om Scrum för en publik som är nyfiken på agila utvecklingsmetoder så är det oftast projektledare och arkitekter som skruvar på sig mest och ställer flest frågor.

Speciellt projektledare verkar ha svårt att se hur sin egen yrkesroll passar in i Scrum. Uppgifter och ansvar som typiskt åligger en ”klassisk” projektledare förekommer naturligtvis i Scrum också, fast i annan skepnad och ansvaret distribueras mellan flera olika personer. Jag ska därför försöka mig på att presentera en översikt över hur de olika ansvarsområden som en projektledare har i ett vattenfallsprojekt hanteras i ett Scrum projekt.

.

Projektledningsaspekter i Scrum

(eller ”Vem ansvarar för vad?”)

.

Varför? Hur ser visionen ut?
Varför bygger vi detta system?
Product Owner
(och kund)
Vad? Vilka features är användbara och värdefulla för kund och användare?
När? Vilka features har mest värde för kund och användare? (Dvs. i vilken ordning ska vi bygga och leverera för att maximera Return of Investment och minimera Time To Market?)
. . .
Kostnad? Hur jobbigt är det att bygga en viss funktion?
Hur lång tid tar det?

Vilka kunskaper behövs?

Scrum Team


Hur? Hur ska funktionen byggas (från ett tekniskt perspektiv)?

Vilken arkitektur och design är bäst?

. . A
Hur? Efter vilka spelregler (process) jobbar vi?

Hur förbättrar vi processen och våra metoder?

Vem ansvarar för att teamet får förutsättningar och möjlighet att utföra ett bra jobb?

Scrum Master


. . .
Problem? Lyfta frågor rörande…

  • Resurser och behov
  • Förändringar i Release planer (omfattning eller tid)
  • Tekniska beroenden mot andra team

…till Meta-Scrum (Styrgrupp) eller till Scrum-of-Scrums?

Alla

h1

I gränslandet mellan Scrum och Vattenfall

tisdag, 13 april, 2010

Nu så har dedikerad testare vaknat till och engagerat sig i ett av projektet jag är engagerade i just nu. Arbetsmetoder börjar ta form, ansvarsgränser målas upp men det tighta schemat genomsyrar hela tiden diskussioner, taktik-snack och projektgruppsmöten.

Test Planen ska diskuteras nästa vecka men jag gissar att jag kommer ha mycket åsikter och synpunkter då den tagits fram med en stor kappsäck av vattenfallsmentalitet trots att projektets testcoach vet om att vi angriper utvecklingsfasen i projektet med Scrum. Min egen roll i projektet är Technical Lead och Scrum Master.

En annan utmaning jag tampas med på daglig basis är kommunikationen med projektledaren. Hon gör ett fantastiskt jobb att koordinera alla parter (stort integrationsprojekt) men hennes angreppssätt är att strikt rada upp allting sekvensiellt och mäta progress i %, oavsett vad det rör sig om. Allt eller inget.  Antingen är det inte påbörjat, X% klart eller helt klart. Inget utrymme för förändring i målbild eller utförande. Dvs. vattenfall. Tilläggas kan att programmeringen och test tar upp ca 10 rader i hennes 120 rader långa detaljplanering. ”Do not touch my perfect plan” får vara dagens citat. (Levererades när jag försökte påpeka att planen kanske borde uppdateras med hänsyn till vår nya kunskap).

Det kommer att bli några spännande sprintar framöver för utvecklingsteamet och mig själv när vi ska försöka leva, leverera och överleva i gränslandet mellan Scrum och Vattenfall. Den uppenbara risken är såklart att eventuella förseningar och/eller problem skylls på den nya kompisen i gänget (Scrum) istället för de sanna grundorskarna (som t.ex. skulle kunna vara dåliga estimat, dåliga förustättningar eller yttre störningsmoment för att nämna några) och att den nyväckta glöden till Scrum i utvecklingsteamet släcks.

Men det är också såklart väldigt utmande och spännande att få vara med att påverka en organisation till att jobba mera agilt och att lära sig fokusera mer på det levererade affärsvärdet, eliminera arbete som är tidsslöseri samt  maximera kontaktytan mellan utveckling och beställare för att bygga så bra lösningar som möjligt. Speciellt roligt är det såklart när stakeholders och teammedlemmar själva kommer med förslag som gör processen och arbetssättet mera agil.

Skulle det börja regna för mycket i vattenfalls-land är det bara göra som man brukar, ta på sig regnjackan och kavla upp ärmarna och jobba på så gott man kan tills man kommer i mål.

För eller senare så tror jag att alla företag som är intresserade av att överleva i en hårt konkurransutsatt marknad måste övergå till en lean organisation som utvecklar agilt.

Jag kommer med stor säkerhet få anledning att återkomma med fler reflektioner, kommentarer och summeringar hur det går för oss att leverera mjukvaran enligt Scrum till ett projekt som i övrigt drivs enligt vattenfall.

Fram tills dess tänker jag falla tillbaka på mantrat:
”Fake it until you make it”!