Building your Village

On Friday the 24th of April I ran an Agile day for my team and others at the BBC, I managed to get some good speakers on a variety of Agile and Development topics - it turned out to be a really good day. The official blog post on it is almost ready to go up.

During the day my mind drifted on to the importance of interactions.

I tend to see a project team as a village, the village should be as self contained as possible - the butcher, the baker and the candlestick maker. Everyone in a village has their part to play in its success. And in a strong village everyone pulls together when times are tough, they come to a fellow villagers aid in times of trouble.

So whilst we may have a team made of specific roles and skill sets the team is greater than the sum of its parts. So as a project suffers challenges the team should pull together to meet those challenges.

I have worked in teams that do this naturally, and teams where its just never quite happened and teams where it never had a chance.

The teams where it worked had a few things in common:

Experience - in all cases the team was experienced, both in software engineering and the problem domain. Each team had at least one problem domain expert, someone who could answer or anticipate the questions.

Attitude - in all cases the team had a strong professional attitude. Not only did the teams strive to minimise technical debt, but all had generally strong work practices. That sense of professionalism actually was strong enough that the team was able to "stand up" to management at those times when it was really needed.

Motivation - in all cases the team was motivated. And typically the motivation came from the enjoyment of working with a great team doing great stuff. Something that is often overlooked.

Now if you had these things you could argue that pretty much any process would work, and I would agree - not all these projects were what we would call Agile today. But they were Agile in the sense of putting People and Interactions, before Process and Tools.

So if your team is not pulling together in troubled times, look at the three points above. Does your team have experience, attitude and motivation? If it doesn't you need to look at how to address it. And you don't need to be the team leader or manager to address it - its amazing what influence any member of the team can have if they are prepared to talk to their team members.

So how do you build your village?

Firstly, interaction. How well does the team communicate? All the members of the team need to feel that they can speak up, and all the members of the team have an obligation to listen. Do you all sit together? If you can't sit together do you use the same watercooler or coffee machine? How often do you have lunch or go to the pub as a team?

I wrote a little while ago about development being a social activity - this follows on that great teams subconsciously understand this. Now by social I don't mean going out and partying, but I mean interacting.

So why do I think interaction on these levels is so important?

Well a team that communicates well will be more fun to work with, it will improve team motivation, it will lead to improved attitude (management by example or culture) and it will encourage everyone to use their experience, encourage people to improve or better themselves.

Its not going to solve the problem of having domain experts, java experts, jvm tuning experts - but you in the end you get to be an expert by doing and learning. Ideally by learning from another expert, but that doesn't have to be from the team, it could be from conferences, blogs, mailing lists, geek nights, books, consultants or from another team in the organisation. Building the right village will encourage the team to learn, to rise to the challenge.