This post originated from an RSS feed registered with .NET Buzz
by Brad Wilson.
Original Post: The Joel Test and Agility
Feed Title: The .NET Guy
Feed URL: /error.aspx?aspxerrorpath=/dotnetguy/Rss.aspx
Feed Description: A personal blog about technology in general, .NET in specific, and when all else fails, the real world.
Randy threw down the gauntlet and asked what agilists think about The Joel Test. The simple 12 question system is supposed to give you a good gauge of how you're doing as a software development group. As we analyze these questions one at a time from the agile perspective, I think you'll agree that the question set is a decent starting place, but nowhere near sufficient to determine if a work environment is sufficient for agile development.
1. Do you use source control?
Of course! Anybody writing source code without source control is insane.
2. Can you make a build in one step?
Yep. In fact, it's a requirement for continuous integration.
3. Do you make daily builds?
Daily builds are too infrequent. Agile teams should build on every commit.
4. Do you have a bug database?
Yes. Believe it or not, agile projects have bugs, too. ;) We also have a system to track work items and stories. Sometimes they end up in the same system, because it's most convenient.
5. Do you fix bugs before writing new code?
Only if that's how the customer wants the work prioritized. Presuming that fixing bugs is more important than new feature is naive.
6. Do you have an up-to-date schedule?
Yes, but not in the way Joel thinks of it. The customer representative has his own external schedules to meet, which usually involve some fixed date (promises for sales, trade shows, etc.). The customer representative is also the person who prioritizes the work that gets done on a week by week basis, so as to best hit the target date with the most important features.
7. Do you have a spec?
Again, yes, but not in the way Joel thinks of it. The customer representative provides the guidance on how features should work. They are the ultimate decision maker on whether a feature is done correctly or not. They may share that with the team in any number of ways; anything from just-in-time descriptions of the features all the way to fully developed feature specifications.
8. Do programmers have quiet working conditions?
Nope, and we're proud of it. Agile teams work best together, and the important word is "team". A team is not a bunch of individuals, working alone, isolated from one another; a team is a group of people who work together all day, every day, towards their goals. A team is more than just developers, too: it's the project management, the architects, the leads, the developers, and the testers.
The truth is that the group work environment works best with a baseline of noise. We play music -- on speakers -- in our war room. The value of this baseline of noise is that people aren't afraid to break the silence to ask questions or talk to the team. The biggest benefit from all being together in a room is that the communication barriers are essentially zero. The ability to turn in or out of specific conversations is a tremendous win for sharing knowledge.
Oh, and don't forget: pair programming!
9. Do you use the best tools money can buy?
Within reason, absolutely.
10. Do you have testers?
Of course!
11. Do new candidates write code during their interview?
Yes, somewhere along the way, the developers will end up writing some real code or pseudo code on a whiteboard during an interview.
12. Do you do hallway usability testing?
We go one step better: with short iterations, we can correct usability issues quickly. Even better, if your customer representative is an on-site full time team member, then they are available for usability questions and testing as the code is being written.
Previous Topic
