1) The analogy to a rugby scrum is unclear: In rugby, a scrum is a way of restarting the game, either after an accidental infringement or when the ball has gone out of play. The practice of Scrum in the software world includes regular short daily meetings where the team members all get together to communicate progress. Because of the similarity of pausing play (work), and having the players (team members) group together this meeting is commonly known as the Daily Scrum
2) I am not a big fan of electronic tools to manage agile projects. Core values of agile methodologies include communication, openness and honesty. Electronic tools to manage work and show progress hides this information from the team and stakeholders. If you use a project wall which uses index cards or post-it notes it is clear at a glance who is doing what. These tools may be helpful for teams not co-located. Teams not in the same vicinity can experience other issues e.g. communication.
3) On a similar point big visible charts on the wall to show velocity and burndown charts give very clear information to everyone in contrast to web based or excel based graphs.
4) It would be interesting to know what issues there were with the group of customers mentioned. There may be a scenario where different people in the customer team have different priorities, how is this situation resolved?
5) Having dealt with agile in various guises for over 4 years I think Ellie has already realised that agile methodologies may need to be tweaked to fit a team, organisation or project. Do not read this to mean take a few bits of say Extreme Programming and then say you are doing agile or xp.
6) Extreme Programming and Scrum fit together very nicely. There is no mention of any agile methodology to drive software engineering best practice e.g. TDD or Continuous integration. Scrum is an agile methodology for project management best practice whereas XP is agile best practice for writing software. This hybrid approach is very effective
7) There is no mention of how the work is broken down and estimated? I use user stories to break down work. I would recommend everyone reads Mike Cohn's book "User Stories Applied"
8) It appears estimating is done in hours. One developer's estimate is going to differ from another’s especially if they differ in experience. I use a method of estimating user stories (in story points) based on how complex they are using a small story as a yardstick. Estimating is also done as a team exercise (Planning Poker: www.planningpoker.com this is very cool!)