1. Code Review
The Slight Edge

2. Development is what we do we do it once
Goal : Agree a set of actions that will form the basis of
our internal code review and release process which will
be followed and visible
• No single change will address all issues this process is intended to change our
working practices by 1%
• Fundamental of Sprint - Acceptance
• Not a replacement for:
• TDD
• Pair Programming

3. The Benefits
• Reduce bugs
• Improves quality of code
• Increases project visibility
• Reduces “key man” dependency
• Verbalise your solution is fantastic for problem solving
• Independent perspective
• Better at estimating
• Increased profitability
• Manage client expectations and assurances

4. The Trade Offs
• Increases development time
• Anticipate a ratio change from bugs and development to testing
• Expecting development to reduce to under six hours a day
• Testing to start to increase
• Slower releases
• Less bugs fixing :-(

5. If you don’t measure it, you can’t improve it
• Dashboard of metrics
• Ours to define
• Weekly metrics
• Actively monitor how we are doing
• Log points excepted versus points completed
• Log number of bugs and chores
• Log number of points accepted
• Set goals

6. Past Sprints
40
30
20
10
0
04/01 11/01 18/01 25/01 01/02
Points Actual Bugs
Chores

7. Next Steps
• Schedule of release timing
• Release process
• pre and post Basecamp
• focus on Acceptance
• PR job to drive for acceptance
• New timesheet category in Loggable for code review/testing
• Commenting
• Automation - How can Jenkins assist?
• TDD
• Future Workshop Ideas
• Ideas...