Prior to working at Highgroove, I worked for a number of softare product companies. One of the best metrics I’ve found for measuring how great a company is to work for as a developer is the Joel Test, which is a list of 12 simple questions. I’ve worked at companies that have scored high and companies that have scored low, and please believe me when I can tell you that the issues on that list really do make a difference.

My only issue with the Joel Test is that it is really geared toward software product companies. While a lot of the ideals translate to a software consulting company, the specific questions don’t always apply when you are working on a lot of projects for a number of clients. So, in an effort the help measure what makes great software consulting teams so great I present…

The Highgroove Test

1. Do you give your customers access to their source code?
2. Do you document projects expecting that your developers will eventually be “hit by a bus” (no longer be on the project)?
3. Do you track results instead of tracking time?
4. Do you promote Test Driven Development?
5. Do you use and contribute to open source?
6. Do you use code reviews?
7. Do you use the best tools?
8. Do you only hire the best developers?
9. Do you require constant learning from your developers?
10. Do you favor simple solutions?
11. Are your developers your project managers?
12. Do your developers deliver code to customers at least daily?

Like the Joel Test, this isn’t meant to be the be-all-end-all list of what software consulting teams should do, but we at Highgroove believe that a team that can answer yes to these 12 questions consistently is a great team to be a part of.

1. Do you give your customers access to their source code?

A developer should never have to feel that their customer doesn’t have access to the work that’s being done. The source code is the client’s property and it’s important to be as transparent as possible.

2. Do you document projects expecting that your developers will eventually be “hit by a bus”?

With many of the developers at Highgroove biking to work though Atlanta’s busy streets this issue is almost more literal than figurative. Each project should have a README with all the steps needed to get the development environment up and running with no outside input. The issue tracker should have all the information on what has been done and what will be done in the project. To achieve this at Highgroove, we make our Pivotal Tracker projects the authoritative source for all information about the project. Nothing should live solely in a developers head.

3. Do you track results instead of tracking time?

Tracking time gives developers the wrong incentives. A software consulting team should push to work as efficiently as possible. Tracking hours pushes developers to stretch work to take an allotted amount of time, and forces them to focus on the clock instead of focusing on cranking out functionality. It’s inefficient and lowers the morale of the team. Your work place shouldn’t just be results only, so should your projects!

4. Do you promote Test Driven Development?

Consultants need to deliver well designed and bug resistant code efficiently and consistently. The best way to do this is having automated testing as a key part of your development workflow. This should be part of the team’s culture. If you are not worried about catching guff for not including tests in that last commit, then your team is not as serious about testing as it should be.

5. Do you use and contribute to open source?

If your team falls victim to the Not Invented Here Syndrome you are wasting your time and your client’s money. Period. Making use of existing, open software allows you to leapfrog ahead and crank out value for your clients. Contributing back to the community can get you great karma, but more importantly better code, great marketing, and the ability for developers to scratch an itch for projects they love to work on.

6. Do you use code reviews?

Code quality should be consistent across all members of the team. One of the best ways to ensure this is to have regularly scheduled code reviews from all different members of the team. As a developer you get yet another pair of eyes to guard against issues with your code and designs; As a reviewer you get to learn from all of the work your colleagues are doing. This is one of the best ways to foster growth in the team as a whole.

7. Do you use the best tools?

This is the only hold over from the Joel Test. This is amended a little because as a developer who uses VIM and Unix for my development environment it felt odd to say “Do you use the best tools money can buy?” A simple idea is encapsulated in this question. If you are a software development team and there is something out there to make your developers more awesome, why are you not using it?

8. Do you only hire the best developers?

I do not want to be the best developer in my team. To clarify, I definitely strive to be the best developer on my team, but I do not want to be surrounded by developers aiming straight for the middle. If a team is great and getting better, you as a developer have room to grow and get pushed to improve every day. Mediocre developers are a liability and can drag a great team down.

One key point about this question is that ability should not be confused with experience. A fast learning developer who is committed to improvement is often a much better addition to a team than someone who has been doing a less than stellar job for a few years.

9. Do you require constant learning from your developers?

Learning should be part of the culture of a great software consulting team. Your clients expect their developers to be up on the latest and greatest. Moreover, encouraging learning helps to keep developers engaged as they get the chance to tinker with new technologies and best practices. Learning is a huge part of what we do here at Highgroove, from our weekly tech talks to our new company book club.

10. Do you favor simple solutions?

While, as a developer, it is always tempting to engineer a bomb proof stats engine that can generate beautiful graphs of everything you could ever possibly want to know, sometimes all you really need is a CSV file that can be opened in Excel. Consultants should focus on giving the client what they really need, instead of what they are asking for on a specific day and give suggestions accordingly. Moreover, there are few bigger drags on morale as a developer than pouring hours into a solution that you know in your heart is superfluous.

11. Are your developers your project managers?

At certain scales having a separate project manager is unavoidable and can be very helpful. However, at Highgroove we’ve found that when we are able to break up projects very granularly and empower developers to manage their own projects, they are much more efficient. With developers interfacing directly with clients, there is much less overhead in communicating issues back and forth. This is more rewarding for the developer and creates more value for the clients.

12. Do your developers deliver code to customers at least daily?

There no longer any reason for a developer to collect requirements, go into seclusion for three months and then deliver code to the client only to have something to be a little off. Tools like Github and Heroku greatly reduce the friction associated with releases so that they can be done multiple times throughout the day. This allows clients to catch issues or change their minds very quickly with a minimum of rework on the developers part. The tighter the feedback loops is, the happier everyone involved with the project will be.

Here at Highgroove, we are very proud to be able to answer yes to all 12 of these questions. We believe that the way we work is a major part of how we do a great job for our clients and what makes us such a great place to work.

What else? Can you think of a better way to test for great software consulting teams?