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)