Tue 29 Apr 2008
In any team work a certain level of discipline is necessary to achieve organized progress. In creative work, however, too much discipline can hinder both the progress and the quality of the results delivered by the team. It has long been known that software development attracts a certain kind of individuals. Usually above-average intelligence comes with an above-average ego plus (usually) some weird interests and kinks. And a certain obsession with tools combined with the love for the art and craft of building software.
For those reasons managing developers has been jokingly compared to herding cats. The manager has to strike a balance, constantly, between the discipline and freedom. This requires discerning what is crucial and has to be monitored closely from what is incidental and can be left for the team to decide or do.
Agile methods make this much easier because they focus on what is really important and really needed for orderly progress. For example Scrum calls for a Daily Scrum each day and besides that it is left for the team to decide how they will work to achieve the goals they committed to during the Sprint Planning. Also, technical level methods like XP or TDD focus more on how the code being built should look like or how should it be built rather than with what, when etc. The rest is and should be left for the people to decide. Some of this deciding will take place on the team level, some will be up to individual developers.
I believe that this is indeed the right way forward and this is how we work at Code Sprinters. We maintain a very disciplined process coupled with lots of freedom in the choice of tools and a very relaxed, informal atmosphere.
One of the things we don’t force on our developers is the choice of tools. They can use Windows or Linux if they want (I wish we could afford to give everyone a Mac as an option too, but this is not possible yet) – and whatever distribution of Linux they want. They can use a company laptop or their own. They can use an IDE like Eclipse or they can use traditional but powerful tools like VI or Emacs. It is so because for the good quality of the end product – software – the developer has to feel comfortable with the tools he uses. Forcing them to use the same “standard” tools would be as wise as forcing them to wear the same size of shoes. I’ve seen comments that “lack of unity in tools” is a bad thing – I strongly disagree with that. I think diversity in the tools used is a sign of a good, creative team.
Of course, there is a minimal set of tools everyone has to have and use, but all are independent of the OS/platform used. Everyone has to use our Banana Scrum tool to manage their tasks and update on progress, do planning it, register impediments etc. Everyone has to have Skype running on their laptop to stay in touch with others and the clients. Everyone has to use Google’s Calendar, our SVN repositories, project wikis etc.
We also don’t strictly enforce working hours. What is enforced is presence on the Daily Scrums – everyone on the given team has to be there – and there are penalties for being late. Besides that it is just said that being in the office is expected and encouraged, but there are no set hours. So we have people running in just before the Daily Scrum and people who sit in the office from early morning. Surprisingly, even without a card-clock etc. most of the time whole teams sit together in our “war room”. It turns out making it both enjoyable and palpably productive to be here works much better than enforcing presence.
Finally, there are certain standards re. the coding style, the test coverage, the way repository is to be used (what is acceptable as commit and what is not), a procedure for starting a new project etc. They are applied universally and teams working on a given projects may (and frequently do) add on top of that additional standards that for their particular project. 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 put the new release in production.
This approach – enforce strictly few key things, be relaxed on others – has worked extremely well for us. I’m not going to say everyone should do it exactly like we (it might be for example a tad difficult with larger teams from the logistics point of view) but I think the general principle is sound and should be part of good practice in any agile team.