I once witnessed a project where there was a customer requirement for source code inspections. The project manager spent a whopping evening "inspecting" 120 KLOC of code and marking them as "inspected".
I'm no Scrum expert, but I've been interested in software development methodologies for a long time.
Scrum has its roots in studies on self-organizing teams. That's why it does not prescribe working practices like collective code ownership, refactoring, unit testing, pair programming etc. It's left to the team to self-organize them if needed.
Historically Scrum is about 5 years older than XP. Therefore Scrum does not need to reflect on XP.
I think to really succeed with any agile methodology, be it XP or something else, you need a highly disciplined and skilled team. With a highly disciplined and skilled team, you can succeed with almost any methodology. Then it comes down to the fun/sustainability factor: you should only use a methodology if the developers are willing to use it on the next project as well.
If you look at the names of the authors, many of them look e.g. Russian. Not all students in Finnish universities speak Finnish.
Who inspects the inspections then?
I once witnessed a project where there was a customer requirement for source code inspections. The project manager spent a whopping evening "inspecting" 120 KLOC of code and marking them as "inspected".
I'm no Scrum expert, but I've been interested in software development methodologies for a long time.
Scrum has its roots in studies on self-organizing teams. That's why it does not prescribe working practices like collective code ownership, refactoring, unit testing, pair programming etc. It's left to the team to self-organize them if needed.
Historically Scrum is about 5 years older than XP. Therefore Scrum does not need to reflect on XP.
I think to really succeed with any agile methodology, be it XP or something else, you need a highly disciplined and skilled team. With a highly disciplined and skilled team, you can succeed with almost any methodology. Then it comes down to the fun/sustainability factor: you should only use a methodology if the developers are willing to use it on the next project as well.