Is Scrum possible without test driven development? [closed]

Question

I have now witnessed two companies move to agile development with Scrum.

In both cases the standard of coding was good enough when each part of the application was only being worked on by one or two developers with the developers spending a reasonable amount of time working on one part of the application before moving to the next task. The defect rates were also reasonable.

However with Scrum the developers are expected:

• to all be able to work on all the bits of the application.
• to only work on one area of the application for a few days at most before moving to the next area
• to mostly work on code they did not write

Code qualities became an issue in both of the Scrum projects.

So is there a way to do Scrum that does not lead to these problems, without first getting all the developers to do test driven development?

Have you seen Scrum work well on a large project without test driven development? (If so how?)

Answer 1

I'd like to expand on what Dan said.

It's a very common misconception that Scrum / Agile dictates software engineering principles. This is a fallacy for many reasons. As Dan mentioned, Scrum is a software management process, NOT a software engineering process. That being said, very often you will see many engineering principles associated with Scrum; methodologies such as TDD, XP, etc tend to complement the management methodology that Scrum promotes, but are not required.

The reason that CI, TDD, and other engineering practices are so often found hand-in-hand with Scrum is that in general, many are good practices to follow no matter what management methodology is used.

I'd like to address a couple other fallacies in your OP:

However with Scrum the developers are expected:

* to all be able to work on all the bits of the application.
* to only work on one area of the application for a few days at most before 
  moving to the next area
* to mostly work on code they did not write

1. As mentioned above, Scrum doesn't dictate what type or kind of work a developer works on. The developers themselves decide on what work to commit themselves to; if a database-heavy dev wants to only work on the DAL and associated stories, there's no reason that they cannot.

2. Again, Scrum doesn't dictate anything about how to build the application, so your second point is moot (see point 1).

3. This is a fallacy, since there is nothing that says a developer should only work on code that isn't theirs, or anything about how a developer should develop. If a developer on a Scrum team finds his/herself only working on others' code, that would be coincidental, not because of the scrum process itself.

See this question/answer for more information on the qualities generally expected in a developer working Scrum.