Keys to a productive environment
Ever notice how some teams can churn out code at an incredible pace while other teams struggle to release features on a regular basis? Sometimes a star programmer can make the rest of the team look very good, but more often than not, a productive team is the result of good teamwork in a good environment. A productive environment also helps you get more out of your programmers thus giving you a better return on your investment.
So here's a list of key points to look out for and ways to improve each of them.
Communication
At one point or another, developers will have questions that need answering by another developer or by a management person. The goal is to enable the discussion to happen without interrupting anyone. There are several communication channels available in a work environment and each one has benefits and disadvantages. The developers should have access to each channel which are emails, instant messaging, group discussions, audio conversations (phone or Skype) and face-to-face interactions.
Phone calls and face-to-face interactions should be used only for emergencies or when the receiver is not responding. Make sure to create a culture where emails and instant messages are answered in a timely manner (a couple hours at most for emails, under an hour for instant messages). If the person did not hear back after a reasonable amount of time, he will escalate the issue and use more direct approaches that might disrupt the creative flow of the other person.
In order to facilitate communications, make sure each member of your team can use the email client of its choice (I'm in love with Gmail for its threaded conversations, but being able to choose between Gmail, Thunderbird, Outlook, etc. is better). Give them a way to send instant messages to each other or have group discussions (Gmail does both, HipChat and Campfire do them better, my vote goes to HipChat for its user experience).
Finally, once you have the right tools, make sure everyone in the team understands the importance of communication and that the junior members know who to contact when they're having issues.
Make projects fun to work on
Not all projects are as interesting as others. There are, however, ways of making a boring project more interesting. It might be an interesting challenge, the opportunity to try a new technology or a new way of doing things. Developers work a lot more on projects they find interesting or meaningful so make sure there are incentives other than money on projects and make sure the developers understand the reason behind doing a project. There's nothing worse than working on a project you think is useless.
Don't leave broken windows unrepaired
Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it's unoccupied, perhaps become squatters or light fires inside.
[...] one unrepaired broken window is a signal that no one cares, and so breaking more windows costs nothing.
An aging code base is usually full of broken windows and so are the various processes in place. Broken windows can take many forms, they can be a bug that no one took the time to fix, they can be a broken build in the source control, they can be a process that is prone to errors, etc. Do not leave known bugs unattended, build a culture where breaking the build is unacceptable (even though it will happen from time to time, make sure the developer feels guilty about it), automate as many parts of processes as possible and reduce the possibility for errors.
Finding a broken window kills the motivation of the team and reduces the quality of the work. Once people start finding bugs left all over the place, they won't bother fixing their own little bugs-that-should-never-happen (but happen all the time in production).
Reduce friction
In the same vein as the broken windows, friction points are annoying and make the work less enjoyable. Friction points can be code without enough comments or features with little or no documentation, making it difficult to change or work with a piece of code. It can be a process that is run often but that is not yet automated. It can be timesheets or timekeeping tasks. The goal is not to remove the task causing the friction, but to make it as easy as possible to accomplish. Time keeping is useful, but taking half an hour on Friday to fill it is not. There are other ways to keep track of time spent working on projects, use them (most project management applications, Freckle, Toggl, etc.).
Provide your team with the appropriate tools and equipment
Give that developer the second screen he asks for, buy that new programmer a decent computer, don't sweat for the purchase of $50 worth of software. A couple hundred dollars worth of purchases could help individual developers and team improve their productivity which will more than cover the expense. Give them the tools and resources that will make them as efficient as possible. Give them access to a decent source control option (decentralized version control systems such as Git and Mercurial will change the way you develop), please get away from source safe or team foundation server. Provide them a way to track tasks and projects (and have your project manager track them and ensure the work is getting done at a reasonable pace).
Finally, give them quiet working conditions with as little distractions as possible, a large desk with a decent chair to sit on and let them choose the rest of their equipment (keyboard, mouse, headset, etc.), developers are picky. They should be able to focus on their work without being interrupted.
37signals and Fog Creek (read both Bionic Office and The new Fog Creek office) have both created amazing work environments and as a result, they can hire the best developers and each company are extremely successful.
