ABSTRACT
As agile methods go, Scrum is unusual. It deliberately challenges the individual and the organization to become disciplined in their approach to so¨ware development. It is deliberately nonprescriptive, making it easy to understand its framework while simultaneously demanding a great deal of focus and involvement if you take it on. It does not talk about writing so¨ware, because the people who put the framework together knew that if you were to get your people working together ‹rst, those people would organize the best development practices for them and make it work because they were empowered to make those decisions. Even well-known and experienced agilists still draw comparisons between Scrum teams and XP teams, saying that XP teams are better because Scrum does not provide the development structure necessary to create and maintain highquality code and XP does. Scrum, when properly taught, emphasizes the fact that a solid engineering infrastructure and solid engineering practices are required to get a good result. More importantly, Scrum emphasizes the “people” aspect of so¨ware development. œat might explain why there are so many more Scrum teams in the world than XP teams. Regardless, when I coach an organization in the implementation of Scrum, I also discuss with the organization its testing and integration practices. I always implement Scrum as a team and work management framework using XP practices like test-driven development, continuous integration, continuous testing, pair programming, collective code ownership, customers on the team, user stories, and so on as a means of creating the solid engineering practices and infrastructure that are necessary.
