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 can be found here.

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.

Something I have been pondering for a while, is “Why is software so hard?”. I know it is hard, I have spent a long time working in the industry, I have seen it fail - thankfully I have seen it succeed (albeit often “challenged”) more regularly. I have read a lot of books and talked to a lot of people, but still I felt something was missing.

Computers are logical devices, they follow your instructions exactly without the slightest deviation - however being human we are not logical, and we do not execute or think naturally in the same precise logical manner. Our brains are non-linear, we make jumps, we shift through varying layers of abstraction and we rarely stay in that logical state for too long.

But that still doesn’t explain why software is so hard. We also have the tools to focus us and guide us when it comes to writing the code. Compilers, unit tests, analysis tools, exploratory testing as well as a myriad of processes attempt to focus us on the problem at hand. So why is it still so hard?

I think one of the leading reasons is this, Software Development is a Social Activity and those that work in software development are stereo-typically anti-social in nature. Yes it is a stereo-type, but it does have a firm foundation in the truth. By in large, we are not social butterflies, we tend to prefer the company of machines to that of humans, the company of our problem domain to that of other people. I hear cries of disagreement from some quarters - yes it is not the rule, there are some highly sociable developers out there.

However time and time again, I have seen software projects flounder because of the lack of both information and ‘social’ bandwidth. By social bandwidth I mean the social interactions between members of the team. Good social bandwidth from my experience requires a very high information bandwidth - face to face communication is good example. This is somewhat difficult to explain, and something I feel that I am only beginning to grasp. Email has perhaps one of the narrowest social bandwidths of all. You have no real sense of the other persons state of mind, their current emotion or their current physical situation. Its even narrower when one or even both parties don’t recognise that fact. We have all witnessed email storms caused by an off the cuff comment at one time or other.

An area of high social bandwidth is the office coffee machine or water cooler. Where people tend to meet, talk and exchange idea’s purely because of the constructed environment - you would not choose to go and chat to a random person every hour or so just for the hell of it (… or maybe you would, maybe you are one of those social butterflies).

Location is a key factor here, as we congregate together to work, we construct a village, a place of community. Now communities don’t always get on, and certainly are not all best friends - but they do tend to build a spirit over time, especially where interaction is unavoidable.

The act of developing a piece of software is the act of a community, it requires a varied team. Just as the village requires the butcher, the baker and the candle-stick maker. The most productive teams recognise and encourage that variation in skills, and tend naturally strive to increase their social bandwidth to spread those skills and experience.

Too many times I have heard a senior manager, who having walked into the office for 30 seconds in a month, complain that a team is not working hard enough - when I know what they heard was actually the sound of productivity, the sound of high information and social bandwidth. A team with a strong bond, can have a chat or a laugh - a positive working environment increases productivity, it makes people want to come into the office.

Now I am not saying the team needs to hold hands and sing campfire songs, but rather the team needs interaction. It needs developers, testers, business analysts, project managers and customers to interact. And the team should foster that interaction both professionally and socially. I’ve seen project managers turn down a pub lunch request which would have done wonders in building a fragile relationship into something more substantial.

It is important that this social drive come from within the team, and not an enforced company social event, one which will leave some feeling awkward or even resentful, and actually discourage some from attending at all. A sense of professionalism can provide that balance, and it is more than achievable with the right team.

When JUnit first appeared, it was perfectly named, however as time has moved on so has its use.

Jim Webber’s recent blog post made a very valid point about when a Unit Test is not really a Unit Test. Test and Behavioural Driven Design push JUnit into an area that is not adequately described as unit testing. Driving a design through testing in this manner means you aren’t (at least initially) writing unit tests.

I’ve also used JUnit in the past to do things which are decidedly not unit testing, its a useful framework to control other sorts of testing. And on more than one occasion have had to explain to a member of management why I used a free unit testing framework instead of using their big expensive shiny testing metaframework thingy.

I am not suggesting that Kent and Eric should rush out and re-release their work under a different name. It was (to me at least) interesting to reflect on naming, and how things progress over time, so once perfectly named entities may gradually slip to the almost perfect. And it is also a reminder that not quite perfect risks gradually slipping to the not relevant at all.

What the perfect name would be today, I don’t know, I think the name is still perfect enough.

Apart from being inherently lazy, there are other reasons why the term “Sprint” irks me….

Agile development is supposed to be about sustainability - in fact the Principles of the Agile Manifesto states …

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

The term Sprint in my mind does not describe a constant pace, it conjures up that desperate dash to the finish line, giving it your all in one go.

The argument is however that “sprints are short”, however they are repeated. Do we expect the Olympic 100m runners to do a 100m dash, and then do it all over again, and again, and again? All in a relatively short time frame, after all how long do you rest between week long Sprints?

The other argument is “its just a name”, however software development is in a large part about naming. Writing clean code is more often than not seeking the right name, something that describes intent - so why should we strive for anything less in naming our processes and their elements?

So until I find something better I will continue to prefer iteration as to me it better describes the intent of repeated time-boxed work.