Produkt ejeren som mere aktiv

I dette projekt har jeg været meget aktiv i hele processen. I følge scrum er en produktejer en kylling og skal ikke være specielt aktiv. Jeg tror dog at jeg vil anbefale at man gør produktejeren mere aktiv for på den måde at få skabt et tættere forhold og dermed mere identifikation. Samtidig giver det også en bedre mulighed for at få uddannet begge parter. Derfor inddrag Produkt Ejeren og kald hende Produkt referencepersonen :)

Hmm it's not working

Så hastigheden er for lav og vi får ikke leveret så vi bliver nødt til at lave nogle tilpasninger med hensyn til hvordan vi scrum'er. Det her er
1) De daglige scrum's bliver nu, hvad lovede du i går, hvad vil du love til i morgen
2) Der vil bliver daglige opfølgninger på fremdrift og identifikation af problemer (impediments).
3) Der vil blive etableret et afhængighedsoverblik.
Den sidste kommer lidt som en overraskelse for mig :) Det er ligesom givet at man kigger på prioriteringerne samt skaber sig et overblik over afhængigheder.

Symptomer på at der er noget galt, men ikke nødvendigvis panik.
1) Ingen proaktivitet på de daglige scrum møder med hensyn til at idenficere Impediments
2) Ingen aktiv commitment på de daglige scrum møder.
3) Impediments bliver identificeret for sent.
4) Selvorganisering og team identifikationen kan nok blive bedre.
5) Hastigheden er ikke så god, men det er forståeligt når man tænker på teamets kompetencer.
6) manglende opdatering af etc'er i ScrumWorks.
7) Der bliver ikke tilføjet tasks til implementering af produktfeatures
8) Estimaterne "ejes" ikke af de involverede team-medlemmer.
9) Alle grisene deltager ikke i scrum møderne.
10) Opgaver/Task bliver uddeligeret af team leads.
11) Der er flaskehals personer.

Scrum smells eller er det noget andet

Så er vi ved at være ved enden af 2 sprint. Det er en helt anden oplevelse end 1. sprint. Der er noget galt med vores process eller også er det ... Jeg kan ikke rigtig sætte en finger på det, men hastigheden er ikke god.
Men jeg tror at det skyldes at opgavens alvor er ved at gå op for teamet. Det betyder at nu skal der leveres noget funktionalitet og de er ikke i stand til det. Vi har allerede fjernet features fra iterationen, men ... Det er ikke så meget at der ikke bliver leveret men mere at der ikke bliver gjort opmærksom på at selv de commitede features ikke bliver leveret. Jeg (som produktejer) skal selv lede og grave i backloggen for at finde det.
Men jeg tror stadigvæk på at Scrum virker og faktisk bliver jeg mere og mere overbevist. Selv med vores implementering af den og en asiatisk tilgang til vidensdeling så kommer problemer op til overfladen hurtigere end i en staged containment process. Så Scrum virker med hensyn til synlighed, men jeg får ikke mine lovede features :(

Sprint retrospektiv - det rå materiale

Jeg lovede nogle resultater fra vores sprint retrospektiv. Det er interessant at observere forskellige gengangere i kommentarerne. 1) Det er tydeligt at teamet er uerfarent med hensyn til prof. sys.udvikling (Eks. lad en anden end dev. teste :)).
Og noget andet er "ja det sagde jeg til jer ... (Eks. baser estimater på kompleksitet og kompentence. Det er det der hedder dragfaktorer). Eller okay så det er derfor scrum siger det skal vi så ikke gøre det? Fast mødetidspunkt for daglig scrum, brug daglig scrum til at rapportere impediments etc.
Det følgende er det rå resultat fra retrospektiven.
Vi holdt den som en start, stop og forsæt seance hvor vi benyttede nogle standard process-elementer som start guide line.
A/D start
- Brainstorming with Architects before start of stages (White Board Sessions)
- Use of Class Diagrams
- establish template for each deliverable
- Start creating smaller and quicker deliverables (1 whole cyle) for analysis and design
- pair programming and walthroughs for critical areas
- During Sprint planning identify which items should have Analysis and Design documents compaired.
A/D Stop
- minimize the number of review handovers by preventing comments (through walkthrough)
- See if it is possible if we don't go back to analysis and design documents if modifications are made during build.
- See if we can combine analysis and design documents
A/D Forsæt
- informal walkthrough of Team Lead, Architect and Customer
- checklist
Build start
- Junit Brownbag
- Junit sit down sessions with Architect and customer
- FAQ
- Revisit Checklists to remove items covered by checkstyle.
Build stop
- Stop limiting yourselves in the design; raise to lead/Architect if there are additional items/updates which makes sense
Build fortsæt
- Test Driven Approach
- Checkstyle
- Checklists
- Continue compliance to standards (ie. Test Driven approach)

Testing (Plan and Execution) start
- Add checklist for Junit
- Brownbag session for creating Test Conditions and scripts
Testing (Plan and Execution) fortsæt
- Execution is done by the person who did not develop

Estimation start
- Estimate base on complexity and skills
- Revisit Estimates after after analysis
- Establish estimation guidelines
- create fixed budget for the walkthrough
Estimation stop
- stop unplanned walkthroughs
Estimation fortsæt
- involve team in estimation

Issue Håndtering Start
- Brownbag Issue Management Tool
- SLA or turnaround time in resolving issues
Issue håndtering stop
- Do not wait for the weekly Issue Meeting raise impediments ASAP
Issue håndtering fortsæt
- Continue Issue Management on a daily basis (red. daglige Scrum møder)

Project Planning & Tracking start
- Delete af red. skab sammenhæng mellem tidsregistreringsværktøjer
- Start learnings from Sprint 1
- spike first before doing unexplored stuff
- Brownbag tidsregistering (red. del)
Project Planning & Tracking fortsæt
- more vocal in saying impediments
- move daily scrums to 9:30AM
- delinquency list or monetary penalty

Review start
- Revisit Dev Process and Update
- Re-rollout Development Process
- Peer review before teamlead Review
- Start more review walkthroughs with architect and client
- Perform Peer Reviews as an alternative for teamlead Reviews
Review fortsæt
- continue all levels of review

Training start
- FAQ or Index List of Links for References
- Værktøj (red.) brownbag before moving to værktøj (red.) Team
- ask questions
- share discoveries during Daily scrums
Training fortsæt
- Lunch and Learn
- Quick sharing of learnings and discoveries of new stuff (ie. Brownbag for spikes)
- Continue being resourceful (use Værktøjer der er til stede, Eclipse)

Velocity et glimrende tool

Ja så er jeg tilbage fra ferie og meget spændt på at opleve hvorledes det er gået med mit produkt mens jeg har været væk. Inden jeg forlod teamet var det rimelig klart hvilke items der skulle laves og hvorledes sammenhængen mellem dem var. Teamet commitede og alt var fryd og gammen :) Okay tilbage. For det første er der lavet om på min prioritering og fjernet ting fra den commitede produktbacklog. For det andet går det laaaaannggsomt, men det er jo fair nok da teamet ikke har de nødvendige kompetencer og det ligesom ikke er gået op for nogen endnu.
Jeg fik lige lavet et meget simpelt regnestykke med hensyn til velocity fra den foregående sprint.
Oprindelig ETC - slut ETC - divideret med antal dage. Det giver en hastighed pr. dag sammenholdt med så meget er der lavet.
Det giver en velocity som godt nok har nogle enhedsproblemer men viser meget tydeligt at med den aktuelle hastighed går det ikke. Det være sig om man benytter ideal eng.days, vingummi, stories etc. som backlog item enhed. Vi har ikke rigtig været dygtige nok til at estimere oprindelig kompleksitet så det eneste der er at arbejde med er de oprindelige tidsestimater og så sammenholde med det sidste. Jeg tror jeg vil introducere nogle kompleksitetsenheder eller noget. Problemet er at vores domæne er meget ukendt og det er lidt svært at etablere en fornuftig enhed.
Vorom al ting er så viser denne meget simple beregning sig at være et glimrende værktøj til at vise potentielle problemer som burndown'en også viser. I morgen skal jeg lave noget trends etc. samt enhedstrylleri måske ...
bliver interessant.

Xp practices

Hejsan
I al min scrum iver glemmer jeg helt at jeg også forsøger at indføre lidt extreme programming practices såsom
1) gruppeestimering estimeringspoker (er vel egenligt ikke xp)
2) pair programing i en ikke så ekstrem grad
3) continous integration med en berto the carpentero bygge maskine, der kører cruisecontrol, checkstyle, junit og bygger etc. Kræver at build.xml'erne er i topform.
4) test-drevet udvikling, den kræver godt nok tilvending så jeg tror at jeg skal være test-driver i de følgende uger hvor jeg vil vise hvordan man kan lave td udvikling.
5) Kunden er altid til stede :) yes sir det er jeg
6) koden bliver skrevet i overensstemmelse med standarderne, vi bruger eclipse/java standarder og sørger for de bliver overholdt mha bl.a. checkstyle
7) Vi itererer og laver små releases (håber jeg).
8) ingen overtid tja den kører ikke helt men næsten
Vi gør sikkert også andre ting som jeg ikke helt lige kan huske. De fleste ting med hensyn til kodning og test gør vi, men design og planlægningen er mine næste fokuspunkter.
til lidt inspiration er her et link til et xp site

Den filipinske eller asiatiske scrummaster

En lille hurtig indskyldelse. Som Scrum Master siger teorien jo at man ikke skal deltage som svin på det daglige scrum møde. (Fordi man ikke er en del af teamet).
Vores scrum master hernede deltager med sine siden sidst og til i morgen. Og jeg tror faktisk at det er en rigtig god idé fordi man på den måde får nedbrudt nogle barrierer samt få skærpet følelsen af at vi er i samme båd. I øvrigt lige et lille billede af hvordan man rigtig powernapper når man er filipiner.

Scrum virker :)

Det kommer vel ikke som den store overraskelse, men Scrum virker. I går havde vi den første rigtige sprint afslutning med demo og hele svineriet. Udover at filipinere har lidt svært med tidspunkter så var det en opløftende oplevelse. Demoerne var som demoer nu engang er. Udviklerne var nervøse og der skete interessante ting. Og endelig så stillede kunden (mig) dumme check spørgsmål.
Den anden del af seancen, nemlig sprint retrospektiven? (På dansk?) var virkelig en fornøjelse. Vi delte
1) der var gruppe arbejde med stop, start og continue elementer til processen (skal se om jeg kan poste den).
og
2) Ting jeg lærte i den sprint og ting jeg vil i den næste.

Ad 2: Rigtig mange af indlæggene handlede om
1) Det teknologisk udfordrene
2) Team og det at arbejde i team.
3) produktfokus
Kender i følelsen hvor man bare sidder og jubler med armene i vejret. Det var virkeligt godt at se at team fokus var en fed ting for de fleste af dem (vi har mistet en i processen). Endvidere var der min. en der sagde at det var fedt at man så hurtigt får lavet noget som man kan se virke. Yes sir.
I lessons learned seancen var der blandt andet kommentarer vedrørende vores daglige scrum.
Hernede har jeg ikke ville blande mig for det er ikke mig der er scrum master. Den daglige scrum har været sådan hen ad formiddagen med de folk som nu har været der. Det har faktisk virket så det er vel et tegn på at ugentlige statusmøder ikke virker når sådan nogle daglige nogle er bedre. Nå men de foreslog at vi indførte en mødeliste hvor man bliver hængt ud hvis man ikke deltager. Endvidere ville vi overveje at indføre en bødekasse, hvor pengene går til vores sikkerhedsvagter hernede.

Der var mange andre gode ting som blev sagt, men det var virkelig fedt at se de her folk selvorganisere, være begejstret og vokse mere og mere.

Lidt gode nyheder

Her i manila er jeg overraskende nok kommet pænt langt med at benytte Scrum sammen med Konsulent firmaets CMMI-5 process. Og det er ikke fordi udviklerne er specielt bevidste om systemudviklingsprocesser samt top notch i domænet og/eller arkitekturen. Det er snarere fordi vi har
1) Et overordnet mål og en vej der hele tiden bliver visualiseret
2) ting der kan testes og vises frem ofte
3) En engageret kunde som er til stede og viser interesse
4) Prædiken og evangelering samt
5) massiv opfølgning
6) masser af reviews
Der er stadigvæk udfordringer såsom
Det daglige scrum møde afholdes kl. 9:00 manila tid hvilket betyder cirka 9:30-40 tiden og de fleste folk er til stede.
Scrum og specielt gruppearbejde kræver evne og selvstændighed til at kommunikere. Udviklerne her er meget unge og uerfarne så deres selvtillid er ikke i top.
De har faktisk noget fremskridt på denne her lille måned. så på den måde må det siges at være en succes, men jeg er åbenbar svær at gøre tilfreds oppe i hovedet. Jeg vil have det spiller derudaf.
De har virkelig knoklet derudaf så selvom alt ikke er helt godt så er de dog på vej. Derfor tror jeg at jeg bliver nødt til at lave noget motiveringsshow. Så jeg har forberedt en lille "sjov" præsentation med nogle billeder fra deres arbejdsdag. Lad os se om de synes om den.