The Sprint Cycle
Magic in Scrum does not come from pixie dust; on the contrary, it comes from the team. Scrum has a two to four week Sprint cycle in which the team delivers their work, driving towards potentially shippable. Potentially shippable – these are two words that often cause teams many headaches and, as my friend Chris Sterling wrote in a blog post, one of the forgotten Scrum elements.
Getting to potentially shippable is a challenge which some call magic, because since Scrum is a project management framework, it does not contain engineering practices. Enter Extreme Programming (XP). XP is comprised of twelve practices. There are some overlaps between Scrum and XP, for example, the planning game and the sprint planning meetings, there are other elements in XP that are absent in Scrum, such as continuous integration, test first and pair programming. While implementing Scrum will help teams, marrying Scrum and XP often brings tremendous results. Understand, however, that implementing Scrum, XP or both is a challenge and going through the motions will not lead to the benefits that management often expects.
The XP practices that I see most commonly implemented, practices which I consider mandatory for the projects that I work on, are
- Sustainable pace
- Collective code ownership
- Test-driven development
- Continuous integration
- Coding standards
At the end of the day, changing the way the team works will need to happen or the issues that were presented in the story above - issues of quality, not having time to test, inability to deliver – they will remain. Scrum will force the change issue and, with time, issues will become resolved. Marrying engineering practices from XP, such as the ones listed above, forces the issue and the change often happens faster.