Tobias Mayer has written a fascinating and valuable article about what it means to be doing Scrum. There are some very practical ideas (e.g. shortening Sprint or iteration length) and some more philosophical ones (e.g. the ScrumMaster role is not always necessary!) It’s a great read, and I agree with everything there, except for one point…
Tobias mentions that one must insist on agile engineering practices when doing Scrum. There are two problems with this.
First, not all development environments have the tools to support the agile engineering practices. For example, one team I coached was using AbInitio; there is no ABUnit test-driven development framework. As another example, a team was doing a software upgrade project where again, there was no easy way to write automated tests (there was a hard way), nor was there any way to do continuous integration short of totally re-architecting the system. Nevertheless, doing a version of Scrum helped immensely.
Second, these engineering practices are even harder to do when the work in question is not related to software. For example, I use agile methods to run my business. I don’t pair program, I don’t do test-driven marketing (at least not in a way that is clearly comparable to test-driven development). These things just don’t apply.
Now granted, Scrum is a software development methodology at its heart. The concept of the Product Owner, the Demo at the end of the Sprint, and a number of other things tie the language of Scrum to software product development. Any time it is taken out of that context, there is a stretch.
Also, please don’t mistake this disagreement with a feeling that quality is something that can be relaxed. I have very strong feelings about technical debt and quality.