Agile Teamwork – Session Notes
These are the notes from the Agile Teamwork ‘Goldfish Bowl’ session. For those who attended they may bring back some memories; for others, they may suggest some ideas.
We were particularly impressed with the ideas of having different customers for different stories, and of shutting down (slumped on the chair) when your pair is taken away!
Charles Weir, 21 September 2005.
Testing
Tester role – hard to fill. Has time and attention divided.
Acceptance test – if produced will it help customers? Functional specification helps defect phase.
Use cases – getting customer involved. Each use case may have a different customer…
FIT testing framework. Helps customers write tests in own language (Word/Excel).
Unit tests vs. Acceptance tests? Acceptance – suite of tests that completes story. Feedback with customer on the acceptance test – Get story straight -> customer, tester, developer brought together.
Difficult to test user interface. DSDM makes Interface designers part of team.
Effective tests difficult. Use Mock Objects.
Pull in random customers to test.
Work in pairs writing the test spec.
Customer Role
Who talks to customer – project manager or developer?
XP wants 1 customer. Different stories may have different customers.
Communicate with customer can be difficult – have to wait for free time? – different ways according to customer – customer must stay owner.
Each Story (not use case) has single owner and test plan. Involves writing Card – conversation – confirmation. Around 1 man week’s effort. Can be implemented in one iteration.
Developer Role
Pairing? Helps knowledge sharing. Defect rates lower. Pair up on support roles.
Problem: What is pair taken away for other tasks? Impacts on measurables, so velocity will take account. If interrupted what does other pair do? Shut down (theatrical but effective) – or carry on.
Estimation – problems. Overestimate early on – important to get together as a team and discuss. If big changes – new requirement not tweak – link to acceptance tests.
SCRUM protocol – if changes too big, stop, then start again. Stand-up meetings daily. Regular iterations – planning
Split stories into engineering tasks – get good feel on progress.