By Andy Brandt
A certain level of discipline is necessary to achieve organized progress. Too much discipline, on the other hand, can hinder both the progress and the quality of the results delivered by the team. This is especially true for creative work such as software development, in part because of the personality traits of people doing it. Software development attracts a certain kind of individual: somebody with above-average intelligence, an above-average ego, a few weird interests and personality quirks, an obsession with tools, and a love for the art and craft of building software. It’s no wonder that managing a team of developers has been jokingly compared to herding cats. The manager constantly has to strike the right balance between discipline and freedom, separating what is crucial and must be monitored closely from what is incidental and can be left up to the team.
Agile processes, which make visible what is most important and truly necessary for orderly progress, can help with achieving this balance. Scrum’s “daily scrum” instills discipline by requiring a fifteen-minute daily meeting where each team member shares what they have completed, what they are working on, and what obstacles they are facing. Other than that constraint, though, Scrum grants the team the freedom to decide how they will work to achieve the goals they committed to during the sprint planning. The tight pressure of a release date being no more than three weeks (the length of one sprint) away is usually enough to ensure people organize their work day in a most productive way. Technical-level agile practices such as XP or TDD are strict about how the code is being built or what it should look like but are flexible about the what and when—decisions of this nature are left to the team and to the individual developers.
This is how we work at Code Sprinters. We maintain a highly disciplined process but allow plenty of freedom, both in choice of tools, office rules, and in adding project-specific guidelines to our universal standards.
Tool Choice
I've seen comments that “lack of unity in tools” is a bad thing; I strongly disagree with that. Diversity in tool choice is a sign of a good, creative team that focuses on what is important rather than trying to appear organized by standardizing the incidental. We don't force our developers to use the same tools. They can use Windows or Linux (I wish we could afford to give everyone a Mac as an option too, but this is not possible yet) -- whatever distribution of Linux they want. They can use a company laptop or their own. They can use an IDE (e.g., Eclipse) or they can use traditional but powerful tools such as VI or Emacs. Why? Because to create quality software, the developer must feel comfortable with the tools he uses. Forcing everybody to use the same standard tools would be as wise as forcing them all to wear the same size shoes.
We do have a minimal set of tools everyone has to use, but all are independent of a particular OS/platform. We all use our Scrum tool to plan, manage tasks and update progress, and register impediments. We require everyone to have Skype running on their laptop to stay in touch with others and clients. Everyone must use company e-mail and calendar, our SVN repositories, project wikis, and so forth. But this is hardly the level of standardization that, regrettably, has been reached at many other companies where everyone has to use the same version of Windows on identical PCs, staring at the same IDE.
Relaxed Atmosphere
In the same way that we don’t mandate tool use, we don't strictly enforce working hours. What we do enforce is presence on the daily scrums -- everyone on a given team has to be there and there are penalties for being late. While being in the office is expected and encouraged, there are no set hours. We have people running in just before the Daily Scrum and people who arrive in the office early in the morning morning. Surprisingly, even without a mandate, whole teams usually sit together in our "war room." It seems that making it both enjoyable and palpably productive to be in the office works much better than enforcing presence.
Universal Standards
Finally, there are certain standards that are applied universally across our organization. These include coding style, test coverage, the way the repository is to be used (what is acceptable as commit and what is not), and the proper procedure for starting a new project. We do not waver on those definitions. However, teams working on a given projects may (and frequently do) add to those existing rules additional standards that for their particular project. A good example is the release procedure, which looks different in each project and ranges from just tagging the release in the repository to working with the client's server(s) to actually putting the new release in production.
Our approach – strictly enforce a few key things; be relaxed on others - has worked extremely well for us. It gives us the discipline we need but allows us the freedom we crave. Following it to the letter may not be practical for every team, but achieving balance should be part of good practice on any agile team.
