Lately I've been pretty critical of the Scrum process, primarily for not containing fail-safes for when things start to go wrong. I spoke with some pretty passionate Scrum Masters who told me, "Don't blame Scrum for a team's failure to adopt it." And I've reached the point where I agree.
For any team considering Scrum I have this advice: If you are afraid of Extreme Programming understand you'll get limited benefits from adopting Scrum. You may get to a point where you work is visible and tracked and possibly even predictable. But you'll lose out on so much more. Like safeguarding your predictability becuase you're missing the increased quality XP brings, or having silo'd technology owners due to lack of collaboration, or inviting inevitable communications issues.
I'd like to see the Scrum Alliance promote both XP and Scrum - and preferably XP first. Because without those developer disciplines the software engineers on the team won't understand what Scrum is all about. And, in my opinion, Scrum does a pretty poor job of explaning exactly what it is and exactly what its benefits are.
Many large-scale software development environments are adopting Scrum but are not close to adopting Extreme Programming principles. Career cube-dwellers tend to like their silos. But without the engineering piece Scrum will remain a Project Management discipline. And it will never be a path to enterprise agility.
My personal focus will be strengthening the Agile principles in my own development work and in those around me:
- Pair programming
- Test-driven development
- Continuous integration
- Technical debt management
- Automated testing
- Acceptance testing
- Exploratory testing
Once those fundamentals form the foundation of a team Scrum can be added as nearly an afterthought.
Technorati tags: Agile Scrum