1. Members
1.1. Wie?
1.1.1. PI
1.1.1.1. Lieke
1.1.1.2. Jeroen Heydendael
1.1.2. CSS
1.1.2.1. Romeo
1.1.2.2. Ruben
1.1.3. OS
1.1.4. NS
1.1.4.1. Marjolein
1.1.5. DC
1.1.5.1. Jerry
1.1.5.2. Rick
1.1.6. UC
1.1.6.1. Sandor
1.1.7. Sales
1.1.8. MT
1.1.8.1. Norbert
2. Doel
2.1. Onderzoeken en stimuleren van de toepassing van Agile binnen Tam Tam om het werkplezier en effectiviteit te vergroten
2.1.1. Door
2.1.1.1. Vergroten van kennis
2.1.1.2. Ondersteunen binnen projecten
2.1.1.3. zelf lerend
2.2. Small group that initaites, encourages, and supports TT's effort to introduce and improve at Scrum (Mike Cohn, succeeding with Agile)
3. Improvement backlog
4. Meetings
4.1. Agenda
4.1.1. Prio bepalen op basis van business value ;)
4.2. Frequentie
4.2.1. 1x per maand bij elkaar komen?
4.3. Inplannen eerste meeting
5. Improvement items
5.1. Kennis en ervaring
5.1.1. Training
5.1.1.1. Zilverline?
5.1.1.2. Norbert zorgt voor budget
5.1.1.3. Alle leden een certificering?
5.1.2. Productowner ervaring/kennis
5.1.2.1. Probleem
5.1.2.1.1. We hebben nog weinig goede product owners binnen Tam Tam. Of mensen die de klantvraag goed kunnen behartigen en vertalen richting het projectteam. (vb: Adriaan is wel een goede)
5.1.2.1.2. nog te weinig kennis
5.1.2.2. Verbeterpunt
5.1.2.2.1. een aantal adviseurs de Productowner certificering laten behalen
5.1.2.2.2. bepalen welke mensen geschikt zijn als productowner (adviseurs / functioneel ontwerpers)
5.1.3. Back log
5.1.3.1. Probleem
5.1.3.1.1. User stories
5.1.3.1.2. Tijdig back-log inschatten blijkt lastig;
5.1.3.2. Oplossing
5.1.3.2.1. Meer ervaring opdoen met schrijven van goede userstories
5.1.3.2.2. Begeleiding tijdens projecten door Silverline
5.2. Sales
5.2.1. contract
5.2.1.1. Probleem
5.2.1.1.1. Het is lastig om een goed Scrum contract op te stellen zonder duidelijk inzicht in scope
5.2.1.2. Oplossing
5.2.1.2.1. Twee vormen aanbieden: Scrum en waterval.
5.2.1.2.2. Eerst met klant backlog opstellen in sprint 0 traject. Dan met Scrum team inschatting maken en minimale/maximale scope bepalen.
5.2.2. opdrachten
5.2.2.1. Probleem
5.2.2.1.1. er zijn (bij CSS) al een tijd geen opdrachten van fatsoenlijk formaat waarin we het goed verder kunnen proberen en ontwikkelen
5.2.2.2. Oplossing
5.2.2.2.1. Het kan zijn dat Scrum voor de kleinere projecten niet geschikt is. Wanneer we toch Agile willen werken zullen we hier met andere vorm moeten gaan werken
5.2.2.2.2. Door teams vast te houden en een backlog per team aan te houden maakt het formaat van projecten niet meer uit. Feitelijk vullen projecten alleen de backlog. Voorwaarde is dan wel dat er vaste teams zijn met een eigen backlog met daarin projecten
5.3. Onderhoud
5.3.1. Release Management
5.3.1.1. Zoveel mogelijk in releases werken
5.3.2. Documentatie
5.3.2.1. Hoeveel documentatie is er nodig voor web projecten?
5.3.2.2. Is standarisatie mogelijk?
5.4. Teams en focus
5.4.1. bij klant op locatie werken
5.4.1.1. Probleem
5.4.1.1.1. niet elk project als scrum verkopen op lokatie, maar meer intern scrummen zodat er wel feeling blijft met TT (bv Jeroen Hulscher zit zo 2 dagen in Woerden en 2 dagen in Groningen ... lijkt me niet echt de bedoeling)
5.4.1.1.2. reistijd
5.4.1.1.3. niet meer aanwezig bij TT
5.4.1.1.4. Portal is langzaam
5.4.1.2. Oplossing
5.4.1.2.1. Rekening houden met reistijd bij plannen
5.4.1.2.2. Deel bij de klant, deel bij Tam Tam werken?
5.4.2. focus
5.4.2.1. Probleem
5.4.2.1.1. er komt iets tussen wat urgenter is waardoor mensen niet tegelijk kunnen werken
5.4.2.2. Oplossing
5.4.2.2.1. focus op afmaken van user stories en klanten waar mensen al aan werken
5.4.3. Team optimalisatie
5.4.3.1. Probleem
5.4.3.1.1. Nog geen vaste teams bij TT
5.4.3.2. Oplossing
5.4.3.2.1. Vaste teams
5.5. Toepasbaarheid op soorten projecten
5.5.1. Ontwerptrajecten?
5.5.1.1. Wat zijn daar de user stories?
5.5.2. Kleine projecten
5.5.2.1. Te weinig iteraties om goed te kunnen Scrummen: is er een andere methodiek beter voor Agile werken?
5.6. Development
5.6.1. Architecture
5.6.2. Automated testing
5.6.2.1. Hier maken we nog te weinig gebruik van
5.7. Tools
5.7.1. Backlog digitaal bijhouden
5.7.1.1. ScrumDesk
5.7.1.2. Axosoft
5.7.1.3. www.pivotaltracker.com
5.7.2. Hardware voor werken op locatie
5.7.2.1. schermen
5.7.2.2. web cams
5.8. Proces
5.8.1. Aansturing MT
5.8.1.1. er is niemand vanuit het MT verantwoordelijk voor de invoering van Scrum. Daardoor checkt niemand die er tijd voor zou moeten hebben hoe het gaat
5.8.2. Uitvoering Scrum principes
5.8.2.1. Volgens mij worden er af en toe trajecten 'scrum' gedaan waarbij het niet optimaal gaat, en wordt te laat de vorm bijgesteld (ik hoop dat het niet in Groningen door blijft gaan met 5 mensen van Martini urenlang erbij), terwijl Scrum juist dit soort van tevoren bedachte valkuilen zou moeten ontwijken door snel dingen bij te stellen
5.8.2.2. Te weinig tijd/discipline om alle randvoorwaarden toe te passen
5.8.3. Kennisgroep
5.8.3.1. Het blijkt lastig om genoeg tijd en focus te hebben om met kennisgroep een Enterprise transition platform te zijn. We blijven nu hangen bij goede bedoelingen en zonder echt mandaat vanuit het MT zal het daar ook bij blijven.
5.8.3.2. Zichtbaarheid voor TT onvoldoende; creatieve manieren verzinnen om zichtbaar te zijn
5.8.3.2.1. maandagochtend
5.8.3.2.2. bloggen
5.8.3.2.3. posters ophangen binnen tt met resultaten
5.8.3.2.4. MT op de hoogte houden