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?)

Leandraleandre

"to only work on one area of the application for a few days at most before moving to the next area" Really? Why? Why was anyone insisting on this? "to mostly work on code they did not write" Really? Why? Why were they doing this? These are not scrum issues. Can you expand on those points? What was going on? – Retroflex

Why did you call it "test-driven deployment" when most people call it "test-driven development"? Why "deployment"? Where have you seen that? – Retroflex

@S.Lott, becouse we all read what we thing we are reading, including you when you read the question yesterday – Leandraleandre

I'm voting to close this question as off-topic because it is not about programming. – Stacey

Answer 1

Regarless of the use of Scrum, what you were seeing was a change from a code ownership approach to a communal code approach. In order for that to work, there has to be a process change which supports it. One such possibility is TDD. There are others (Automated unit testing even if doesn't drive design coupled with Code Reviews, strong design communication, greater design up front, not developing on code without first pairing with the original author on the code, and more I'm sure you could think of).

Communal approaches work in smaller communities (in large ones it can degenerate into a tragedy of the commons) with a high sense of cohesion between the members.

Mond

thanks, you may have hit it on the head – Leandraleandre

Answer 2

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.

Judaic

I wish I could +10 this answer. – Unchartered

given that most stories go from UI all the way to the database and back again and it is normal for a story to be worked on by a single developers, I don't see how a developer can choose on to work just the DAL and associated stories. – Leandraleandre

Maybe the dev just picks technical stories, or maybe the dev picks the story, does the DAL work, and hands the story off to a different team member. Because the team as a whole commits to completing all of the stories in a sprint, there's not really the issue that a dev has to work on every aspect of a given story. There's also nothing to say that a scrum team can't write their stories that are DAL-only or some other specific area or service, e.g., "...Allow consumers of the AwesomeService the ability to...". – Judaic

@Ian Ringrose. Scrum is about the team committing to produce results, and the team being empowered to decide how to do so. If that means 1 dev per user story, great. If that means 3 devs per user story thats fine also. Whatever way the scrum team believe to be the best way to do the job is what should happen. – Deville

@Josh E, I think that depends on if AwesomeService has any value as a customer facing thing, otherwise, although doable, your scenario raises integration headaches and cracks in the code where there is no clear line of responsibility. – Mond

Good points Yishai, I think that Paul Rowland encapsulated what I was trying to convey better than I did! – Judaic

Answer 3

Yes, Scrum describes the software management approach. The program and project management paradigm should not dictate whether or not you use test driven development.

TDD is a software development practice or technique and although it works well with Scrum I don't think it will make or break your success with the practice.

I have personally seen Scrum work well on medium sized projects without a test driven approach to development. That is not to say we didn't write automated tests, they just were not always written first.

Sturrock

so can you do Scrum without having every programmer being made to work on every bit of code? – Leandraleandre

although it can help, I personally don't think it is necessary. with any project of significant size it just isn't feasible. – Sturrock

it doesn't make a whole lot of sense from the efficiency standpoint to have devs work on every bit of code IMO. There is a huge amount of value in informal peer code reviews however. Making two devs working on different pieces of code walk their respective sections through with each other has shown big payoffs on my team – Judaic

would you say that scrum could work with no automated tests? – Leandraleandre

I would say it can work without any automated testing, and it goes back to the point that scrum is a management methodology, not an engineering methodology; any project would likely benefit from automated testing – Judaic

Answer 4

We do Scrum at work, but we don't practice TDD. Nothing in the Scrum "guidelines" tells you that you have to use TDD. In fact, most agile practices are merely a recommendation insofar that they have proven to work well in agile environments (or even non-agile ones) without them being a must if you want to implement Scrum.

We do write lots and lots of unit and integration tests to avoid extensive manual testing and ensure that later changes in the code doesn't lead to any unpredicted side effects. But that's not TDD. It's mostly a sensible approach to ensure good code and software quality.

Please note that not implementing TDD was not an "active" decision, it just happened. We are encouraged to "write tests first", e.g. when fixing a bug, so it's kind of a voluntary situation-driven not-obligatory way of getting a feeling for TDD by applying it on a regular basis, but it is not mandatory.

Like others said: Scrum is a framework which can hold whatever practices you want to enforce in your development team. Some agile practices come naturally, because they generally make sense, but which ones you want to use and which ones you don't want is up to you.

Whinstone

This is basically how we do it too. TDD is great for bug fixes, but really stinks (IMO) for any full-fledged development since it inhibits fast major refactoring. – Bronwynbronx

Answer 5

Yes, Scrum is entirely possible and in most cases implemented without utilizing a TDD approach.

However, the flexibility that TDD provides is certainly something that a Scrum methodology can benefit from.

Knitting

Answer 6

The main project I work on uses a Scrum approach but the embedded nature of our project makes test-driven development (the way that most people do it) impractical.

I think the problem you encountered was that the expectations of the programmers changed, not that the management process went to a Scrum-style system. If programmers are constantly being shuffled around to parts of the code they are not familiar with, investigate the process behind how tasks are being delegated relative to the old method. Are tasks being assigned to the developer who knows that area the best or are they going to the developer with the shortest to-do list? Is there a long backlog of to-do items for one part of the code and a scarcity of to-do items for another part? If you want to keep developers focused on the areas they excel in, then project management will want to adjust sprint lengths and task priorities to make sure that the workload can be distributed as desired and still be feasible given the time constraints of the sprint.

Craig

Answer 7

The Scrum framework is pretty small, it defines a few meetings, ideal lengths of iteration, responsibilities of product owner, scrum master... and maybe a bit more.

However, once we have started our iteration there is nothing in Scrum that dictates how and when a developer(s) should develop something. There is only the committment it will be 'done' by the end of the sprint.

Scrum is about the team committing to produce results, and the team being empowered to decide how to do so. If that means 1 dev per user story, great. If that means 3 devs per user story thats fine also. Whatever way the scrum team believe to be the best way to do the job is what should happen.

To answer the question, yes Scrum is possible without test driven development.

TDD is a worthwhile/recommended practice but the results will vary depending on team/context. For example was TDD in place at the start of a project or are you trying to inject the methodology in at a later date.

Deville

Answer 8

There's some confusion about Scrum here.

Scrum per se doesn't tell you how/when to do technical things like TDD (that's a forever moving target). Scrum tells you how/when to manage the people things that happen on a project. It is a overall project management technique, not a construction management technique.

If your manager wishes to do the three things listed above during your sprints, that's fine, but that isn't part of the framework of Scrum. Those are for construction management, which isn't Scrum. It may be used in your Scrum-framework-bounded project, but it isn't in the official Scrum framework.

I think it's easy to be confused about this, though. Agile techniques like Scrum are usually evangelized by people on the 'net who are all about pushing buzzwords and 'happy shiny' things, and as such don't always understand/communicate well. At least, that's how Agile techniques were introduced to me, by an Agile apologist. It took me a good 6 months before I got past the hype / confusing terminology and figured out what they were talking about.

Energy

Answer 9

While there are parts I agree to above, I truly believe that you cannot deliver small increments of Code (Scrum for software) without Testing period.

How do you know your sprint didn't break the last 4? How can you guarantee deliverables if you don't know that you didn't break anything in the past.

While I do agree SCRUM is a management process and that TDD is a software process. You must have some way to be able to verify that you did not move backwards.

SCRUM teaches you that daily deliverables and always moving forward at the expense of speed.

When someone says I want to do CI or Agile or Scrum, to me this automatically means there needs to be unit testing (not integration testing as mentioned above) but rather each individual moving part has it's own unit tested.

If you do an integration test you are not testing each individual part in a self contained way. Therefore all you prove is that the method called in one flow works rather than each possible branch you would see in the MSIL

Horary