I really like the Joel test, use it myself, and encourage my staff and interviewees to consider it carefully. However I don't think I can ever score more than 9 because a few points seem to contradict the Agile Manifesto, XP and TDD, which are the bedrocks of my world.

Specifically: the questions about schedule, specs, testers and quiet working conditions run counter to what we are trying to create and the values that we have adopted in being genuinely agile.

So my question is whether it possible for a true Agile shop to score 12?


On recommendation from an answerer below I am adding a link to my blog where I originally wrote about this and which led to me wanting to post the question here.


I'm putting this in because I agree with much of what has been said below and I wanted to declare my full position.

  • 3
    I am skeptical of the notion of a "true Agile shop" since it implies there is one prescribed way that must be followed by all development teams. Also the answer to this question will vary depending on the exact methodology used. Agile is a collective term for a lot of approaches.
    – JohnFx
    Mar 16, 2011 at 14:59
  • you're right, we use XP, but I wanted to have as broad a conversation as I could.
    – Simon
    Mar 16, 2011 at 15:02
  • 3
    No. It is never possible. This is so Joel can lure you to his company by making you think they are a better place to work, but then he will enslave you and you will toil in his underground mines forever! Mwahahahaaaaa! Mar 16, 2011 at 19:58

5 Answers 5


My point of view as an agilist:

Do you use source control?

Yes, of course, continuous integration, part of XP needs a source control system to be able to commit code to it.

Can you make a build in one step?

Yes, the continuous integration server is there for that.

Do you make daily builds?

If we can make it in one step, we can schedule it.

Do you have a bug database?

Yes, any "Agile project" management tool can track bugs and added in scrum product backlog

Do you fix bugs before writing new code?

Yes they are prioritized in the product backlog

Do you have an up-to-date schedule?

Yes always, thanks to the product backlog, iteration backlog, release plan & accurate estimations that come with it thanks to Planning Poker.

Do you have a spec?

Yes each User Story come with more details if needed. We also encourage communication between the product owner and the team.

Do programmers have quiet working conditions?

Yes, a room with 8 developers is usually very quiet. We try to not put the sales men in the same room.

Do you use the best tools money can buy?

Yes, while we value individuals over tools, don't worry Joel, we purchase a license of all your products ;)

Do you have testers?

Yes and they are an integral part of the team.

Do new candidates write code during their interview?

Yes, and the team is involved in the process.

Do you do hallway usability testing?

Yes our testers help us with that.

  • 26
    I've never seen a room with more than 3 developers be quiet. Mar 16, 2011 at 15:02
  • 3
    @whatsisname: playing Quake 3, for sure ;)
    – user2567
    Mar 16, 2011 at 15:05
  • 5
    Quiet doesn't means dead. It means there are no distractions when yoy want to get to the zone. A small team working together (agile working conditions) separate from the rest (product owner watch for not disturbing developers in the middle of iteration) is quiet and stimulating. Music is ok, some chat is ok.
    – helios
    Mar 16, 2011 at 15:06
  • 3
    @Simon: "I can't quite call user stories "specs"". "I can't quite call our planning activity and wall a "schedule"" In which case, please update the question with your specific issues. Those are Agile best practices. If you don't like them, please explain why you're rejecting those two Agile best practices. "I also struggle to call our quality engineers Testers" That's a personal problem -- nothing to do with Agile.
    – S.Lott
    Mar 16, 2011 at 15:27
  • 10
    +1: "We try to not put the sales men in the same room." Can I work for you please?
    – Tom Morgan
    Mar 16, 2011 at 15:55

Do you have an up-to-date schedule?

This is Agile. Scrum requires us to commit to a release. Having an up-to-date schedule means knowing what will be done (and will not be done) in the release, and what the backlog looks like.

Do you have a spec?

This is Agile. An architecture (and the associated description) is essential. This specifies the form. Use cases (or user stories) are essential and specify the functionality.

Do programmers have quiet working conditions?

I can't see how Agile requires a noisy, disruptive, annoying environment.

Do you have testers?

Um. When we do TDD, we are testers. When we hand the code over to the product owner, additional testers may be involved before the customers are involved.

How does this contradict Agile methods or the Agile manifesto?


I think the answer is yes, an Agile shop should be able to do this. Specifically to your points.

  • Scheduling is about having a clear definition of what features you are planning to tackle. This definitely achievable.
  • "Quiet working conditions" is not about the sound in the workplace, it is removing non-project/programming noise. It is about keeping your programmers from having to use effort to block out distractions
  • Agile shops should be testing early on and having someone other than the developer testing the code is really what Joel's point is about.

Why do you think having a schedule (to take one example) is incompatible with Agile development?

It's highly unlikely that you'll be working from sprint to sprint with absolutely no idea of where you want to go with your product. Yes you will need to revisit and revise the schedule after each sprint, but you will still have one.

Having a statement like "in Q1 we plan to release features A, B, C and in Q2 we're currently looking at features X, Y, Z" is still a schedule. There's every chance that X will become W but that's what being Agile allows you to do.

Taking another thing from your list - Specs. What's a User Story if not a specification?

  • 1
    Semantics, perhaps, but these are some very loaded terms. A release plan I agree with. A schedule I do not. I would argue you have no idea exactly what you'll be working on one iteration out. You know what you intend to do, but probably won't always stick to it. Isn't that the whole point of being agile? The problem is that if I say "schedule" to anyone outside dev they have certain expectations, and I deliberately don't hold to many of them. Worse if I ask "do you have a schedule?", then someone who has a mile-long GANTT chart will also say yes and I cannot be told apart from that.
    – Simon
    Mar 16, 2011 at 15:16
  • 1
    @Simon - I suppose it is semantics, but the argument still stands. These things are not totally incompatible with Agile methodologies.
    – ChrisF
    Mar 16, 2011 at 15:20

I guess I am going to look at this from a different perspective than most here. If you are scoring a 9 on the Joel test, you are ahead of the curve. A lot of places would struggle to hit a 5 or 6, let alone 9 to 12.

Are you having a hard time hiring good people? If not, then a 12 on the Joel Test, while a noble goal, may not really be an issue. If your employees are able to function in the environment that you have, I would say good job for scoring as high as you have.

  • I think my current workplace hits about a one and a half, and other places I've seen are less than that. 6 would be awesome. Mar 16, 2011 at 22:45
  • Yeah, exactly. We hit 4... Mar 16, 2011 at 22:48
  • I don't think I've seen anywhere, in 15 years, that would score higher than 2. Mar 17, 2011 at 0:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.