1. ICSM and Extreme Programming(XP)
Tim Wahmhoff

2. Extreme Programming Agile process Rapid development Embrace change
Less focus on documentation, more on coding
Rapid development
Working version to the customer as quickly as possible
Embrace change
Short development cycles
Plan for change rather than attempt to establish stable requirements

3. Lifecycle

4. Similarities Emphasis on customer satisfaction User Stories Testing
XP –Get to know the business process
ICSM- WikiWinWin Conditions
User Stories
Combine requirements and use cases
Testing
Both emphasize unit tests and acceptance testing
Requirement updates
Similarity is both expect requirements to update and change throughout the cycle.
Difference is that most of XP changes come during development of the system.

5. Differences I consider ICSM advantage
Design with whole system in mind
Better system architecture
Documentation
Development is slower, but transition is easier
Doesn’t require experts
Heavyweight generally better for less experienced developers.

6. Differences (Advantage XP)
Early development
The sooner you give the client something to play with the sooner you can start getting feedback
Improves ability to actually assess how much work a requirement is going to be and keep client updated.
Short development iterations
Not actually prohibited by ICSM in 577ab
Pair programming
Again, although not prohibited in any way by ICSM, I think its incorporation into the 577ab development process could improve productivity

7. What is pair programming?
Two programmers working side by side
Design, Code, Test as a team
Driver
Controls keyboard and mouse
Actually does the coding
Navigator
Provides strategic planning
Looks for defects

8. When to use it Novice-Novice attacking complex problem
Experiment with repeat programming
Greatest benefit when both are inexperienced with implementing the feature
Implementation of simple or familiar problems decreases the REAP

9. How and When for 577ab
When team encounters non-trivial, unfamiliar feature
When working on parts of the system that are critical to implementation of other parts of the system
Training a novice
One expert in a large section of the project
Expert is the Driver
Novice is the Navigator

10. Advantages of using pair programming
Couples programming and debugging/code review
Code reviews are more effective
Know what you are reviewing
Better designed and more extensible code
Forces communication with regards to the code
More Fun!

11. How 577ab would change
Lab session to teach the basics of pair programming
Assign a fairly simple problem to complete as a pair
Driver vs. Navigator roles
In the case of an unsettled dispute default to the driver, argument decreases group productivity
Prior to prototyping if possible

12. Potential Difficulties for 577ab
Overlapping Free Time
Programmers strongly opposed to working in pairs
Not an anticipated problem for all, but some personality types can clash
Collocation
Requires sharing a computer

13. Short Development Iterations
Reasons
IKIWISI
Need client feedback
"Optimism is an occupational hazard of programming, feedback is the treatment.”
MuSCoW updates still satisfice.

14. How to change 577ab to incorporate
No change in the ICSM, this is already allowed.
Incorporate into weekly client meetings
No new reports
Require client meeting notes to contain product feedback as well as what was demonstrated.

15. Conclusions
ICSM could improve even more by incorporating some the practices of Extreme Programming
Pair programming
Better designed, more reusable code
Essential features created faster
Short iteration cycles
More customer feedback