Scrum teams typically work in iterations (called sprints) that are from two weeks to one month long.
Scrum product owner prioritizes the product backlog but the team determines the sequence in which they will develop
XP teams typically work in iterations that are one or two weeks long.
XP teams work in a strict priority order.
XP and Scrum
Scrum teams do not allow changes into their sprints.
Scrum doesn't prescribe any engineering practices
XP teams are much more amenable to change within their iterations.
XP prescribes engineering practices, particularly things like test-driven development, the focus on automated testing, pair programming, simple design, refactoring.
We help each other succeed. This practice comes from XP.
Pair Programming
When you pair, one person codes—the driver. The other person is the navigator, whose job is to think
The driver focuses on writing syntactically correct code.
The navigator sometimes works on understanding how the current work fits in the over-all design and sometimes thinks of the next task.
Since we are trying to do simple design things are evolving the developers require a lot of discipline and pair programming enforces this.
This form of development is very resilient to external interruptions.
Above all it allows and forces individuals to collaborate and share knowledge.
Pair Programming- Challenges
Pair programming can be uncomfortable in the beginning, especially if you are not used to collaborating.
Comfort needs repeating.
Communication issues.
Organizational buy-in - Isn’t it more expensive?
Continuous Integration
We keep our code ready to ship.
At heart this is stop the line culture from TPS.
Continuous Integration
The ultimate goal of continuous integration is to be able to deploy all code.
Although you won’t release in the middle of a sprint, the point is to be technologically ready, even if you are not functionally.
With Continuous integration, you are integrating in short cycle and thus have smaller changes to deal with as you integrate.
Continuous integration does not make sense unless it’s automated, has a short turn around time (fast builds), and everyone owns the concept of Green Builds.
You need tests to fail or pass a build. Tests are the backbone that give you a green or a red light to take a snapshot of your build.
