Andy's Mind

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.

I’ve just spent (I wouldn’t say wasted) half an hour browsing through a collection of old photographs made available by the Library of Congress on Flickr. Images of a world long gone, so old that even children depicted on those frames are most probably long dead. And a thought came back to me that I had years ago when first really reading up on the history of late 19th century: how easy it was, in a sense, to live one’s life then. The society’s values and roles were very clear then. No doubt as to what was wrong and what was right – everyone was believing in the general set of values based on the ten commandments and moral teachings of Christianity. Not everyone followed them – liars, murderers, thieves, deviants and the like were with us always – but no one questioned them. Most of insanity we see every day on the news now, including all possible perversions, was not thinkable or – at the vert least – was limited to single cases on the fringes of the society. No question then why general decency prevailed – no one posited immorality as a norm.

It very well might be that while we have much developed since then technologically as a culture we – Europeans – have rather declined. The turn of the 19th and 20th century was, I think, the golden age of our culture – even though the first seeds of the catastrophic 20th century were there already. Good that at least we have those images to remind us of times when right meant right and wrong meant wrong.

To make my life easier with introducing people to Scrum I did prepare a short presentation. You can view it here.

And, BTW, I’m happy to report here that a new version of our Scrum tool – Banana Scrum – was released last Friday. Development is still going on, even though I can only put people who are not engaged in other projects on that work.

Right now I decide we’ll do a sprint concentrating on “cleanup” – mostly features or development that aims at improving overall usability and compatibility with different browsers. Even though IE 6&7 + Firefox + Safari work flawlessly we had some problems with Opera.

Another project that we have been working on is now available for preview. This time it is a simple tool for managing the Scrum process called “Banana Scrum”.

You can log in to the preview installation by following this link and using the name “admin” and password “test”. You can play with the application as much as you want – it works on a copy of the test database that is regularly refreshed, so you can move and delete and edit whatever you like.

This project was born out of our frustration with ScrumWorks. It was the application we have used for the most of last year, because it was the only free and decent Scrum software around when I went looking for it in January 2007. However, it had many serious limitations, exorbitant pricing for the “Pro” version which added basically access rights for user (not needed for small teams IMHO) and was done as a Java app – a design decision I couldn’t understand, since there is absolutely nothing in there that could not have been done with an interactive, AJAX web app.

That is exactly what we did – our little Banana is done fully in Ruby on Rails, works great with most browsers and supports interactive features like in-place editing, drag and drop or a nice, interactive burndown chart. As of now it is pretty useful and – as it supports multiple projects – we use it for our own work.

We hope to add more features soon and possibly some day make it available to the world. If you’d be interested in trying it already – drop me a line.

As for the name… well, there was a competition in the team and Tomek Paczkowski won it (and a bag of bananas) with this proposal.