For personel interest I decided to read chapter 4 „Team Logistics“ of Agile Testing, before we decided to do so in the book study group, here is my outcome:
- Team Structure communication is critical!
- Independent QA teams
- lead to division between programmers & testers
- are inefficient
- structures & reasons should be changed
- testers as learning CoP, QA managers as „leader“/ „teachers“
- Integration of testers into an agile project
- testers (also) need training -> critical/ crucial
- programmers need training on testing (skills)
- pairing of programmers & testers
- improves communication
- is efficient
- only 1 budget/ schedule
- -> how does this fit into a big organization with multiple scrum teams and multiple independeent QA-teams?
- testing as part of the DoD
- testers are full fledged team members (use retrospective to improve)
- testing tasks are as important as all other tasks (use retrospective to improve)
- new definition of QA & development managers to be found
- Agile project teams
- cross-functional, but „whole team effort“
- build team depending on project´s needs <- refactor as needed
- tester´s CoP, driven by QA manager
- Independent QA teams
- Physical logistics
- -> Co-location of all team members!
- support communication of distributed teams (phone, webcam, instant messaging, …)
- Resources
- tester-developer ratio
it depends… on- complexity of the AUT
- skillset of the tester
- used tools
- -> number of test taks taken by programmers (?)
- focus on skills instead of ratio
- use retrospectives to find out if hiring a tester would solve the problem (!)
- tester-developer ratio
- Hiring an agile tester
- Very similiar article online: http://lisacrispin.com/downloads/HiringAgileTester.pdf
- most important: does person fit into team
- „hire for attitude“ (not skills)
- Building a team
- self-organizing team: team can identify & solve problems on their own -> best progress
- involving other teams: bring teams together, so they can learn from each other
- performance and rewards
- measuring & rating individual performance risks undermining team collaboration
- good performance shouldn´t be victimized if team doesn´t perform well
- don´t blame the tester if a bug gets discovered in production
- set goals which
- serve business
- increase profibility
- make customers happy
- -> generalized(?): which add value?
- celebrate success
- What can you do?
- get team principles from chapter 2 to work
- communication
- feedback