18

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?

Edit:

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.

http://simonpalmer.com/2011/03/16/why-i-will-never-score-more-than-9-on-the-joel-test/

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

Simon
  • 379
  • 1
  • 5
  • 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 '11 at 14:59
  • you're right, we use XP, but I wanted to have as broad a conversation as I could. – Simon Mar 16 '11 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! – FrustratedWithFormsDesigner Mar 16 '11 at 19:58

5 Answers5

21

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. – whatsisname Mar 16 '11 at 15:02
  • 1
    Sounds like the the answers are an implementation detail :) Hallway usability is easy in an agile enviroment, and specs only need to be as big as the people designing them want. Many little ones or one big one - doesn't matter which. The important thing is that you plan and have records of that plan. – Michael K Mar 16 '11 at 15:04
  • yeah, I guess we are going to get into semantics. I can't quite call user stories "specs" and I can't quite call our planning activity and wall a "schedule". They are in only the most generic way. I also struggle to call our quality engineers Testers and we definitely don;t have a quiet working environment. The last one is the only place we differ really. Our working environment is quite noisy, there's a constant burble of conversation and laughter - it's not the library, it's more like the refectory. – Simon Mar 16 '11 at 15:04
  • 3
    @whatsisname: playing Quake 3, for sure ;) –  Mar 16 '11 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 '11 at 15:06
  • not trying to shamelessly blag my blog, but I have written about my answers http://bit.ly/gjZoUt – Simon Mar 16 '11 at 15:08
  • @Simon: interesting. I added it in my answer, so we keep track of it. –  Mar 16 '11 at 15:13
  • 2
    @Simon: tinyurl, not clicking – whatsisname Mar 16 '11 at 15:20
  • 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 '11 at 15:27
  • @Simon: I wasn't aware you where the OP. Removed your link. Please add it in your question as it where it should be –  Mar 16 '11 at 15:36
  • 10
    +1: "We try to not put the sales men in the same room." Can I work for you please? – Tom Morgan Mar 16 '11 at 15:55
  • 1
    @Simon - if your agile testers don't care to call themselves testers, I guess they've never heard of Elisabeth Hendrickson, Lisa Crispin, Janet Gregory... – testerab Mar 16 '11 at 22:35
  • @Pierre 303, I put the link to my blog in the first question I asked and it was moderated out of existence, probably on the grounds of being spam - although I have no evidence of that. I'll try putting it back in. It does expound my position a bit further. – Simon Mar 17 '11 at 18:02
6

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?

S.Lott
  • 45,264
  • 6
  • 90
  • 154
4

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.
jzd
  • 4,166
  • 25
  • 28
3

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?

ChrisF
  • 38,878
  • 11
  • 125
  • 168
  • 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 '11 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 '11 at 15:20
0

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.

Jesse McCulloch
  • 1,124
  • 1
  • 11
  • 13