- We embrace pair programming more, especially for code which is being used by various people (non UI related)
- Emphasize shall be payed on how we implement stuff, it does not mean starring at other peoples' screen during coding
- We want an agreed consensus so that the implementation is less prone to change after it has been implemented and people actually had a look at what it has to offer
- Keep branches up to date with master, pull master at least daily
- Poke people in chat when something they were waiting for has been implemented
- Scrum master is responsible for having knowledge about all weekly user stories and their implementation
- He must be able to present them during the AT without "help"
- Guy implementing user story/feature is responsible for showing it to the scrum master before the AT
- The deliver on a user story shall only be clicked when the feature has been shown to scrum master/team (friday session)
- Friday before lunch (11:00 o'clock) is internal AT session to test for the presentation
- Last opportunity to show ones feature to the scrum master (!)
- Friday after the AT the sprint review session is scheduled
- Coding without lots of documentation and communication works fine as long as components are clearly separated
- Agreeing on common patterns and abstraction helps integration of separately developed components
- We should've reviewed the complete set of user stories more often
- They overlapped, were duplicate and sometimes are quite ambiguous
- Pull requests help other people to gain insight in development of features
- The team can review ongoing work which leads to early error correction