On engineering practices in Scrum

The following couple of articles helped me to understand better the nature of the Scrum.

When is Scrum not Scrum? by Tobias Mayer and Differences Between Scrum and Extreme Programming by Mike Cohn

Both articles pay special attention to using engineering practices in Scrum. Both agree on importance of the practices and their value for the development process. More radical Tobias (he was expelled from the Scrum Alliance) thinks that they should be mandatory. Mike takes less categorical approach.

This is the bullet point list from "When Scrum is not scrum":

1. Product Owners are part of the team.
2. Two-week Sprints
3. Tasks are not measured in hours
4. Use of Taskboards rather than spreadsheets
5. Backlogs on the wall
6. Estimation Meetings
7. Insistence on Agile Engineering practices
8. The Scrum Master role is not always necessary

Here is an excerpt from Mike's article:

"I find true XP to be a small target off in the distance. If a team can aim at that and hit the bull’s eye, wonderful. If not, however, they are likely hacking (e.g., refactoring without any automated testing or TDD). Scrum is a big bull’s eye that on its own brings big improvements simply through the additional focus and the timeboxed iterations. That’s a good starting point for then adding the XP practices."


-Alex