The other day I found myself (yet again) explaining to someone my interpretation of the phrase “a good team”. It is a phrase referred to a lot in agile. Some people seem surprised it is even open to interpretation at all.

To be clear, “a good team” means a team that “understands the behaviour (business rules, logic and so on) of the aplications we support or are building, so that they can become productive as swiftly as possible”.

Most applications have business rules and logic embedded in them. Often this is invisible to the user. If it is not well understood, our project will have problems. It’s that simple. These problems aren’t a reflection on the people in the team, or at least aren’t down to their technical skills. Or even their ability to apply those skills. It goes beyond that. If you are faced with I’ll-understood code, even ‘world-class’ (whatever that is) developers, analysts and project managers will struggle. They are not “a good team”. Sorry.

Some people will step in at this point and say “ah yes. But we can ask our customers or our BA”. They will know how it all works.

Really? Even for behaviour invisible to the user? What if we have new people? What then?

Possibly the team wouldn’t struggle if they were building something completely brand new with no legacy to it. This is a situation that most developers (or all of us come to that) generally want to be in, but can’t.

The above also assumes there is a stable set of people. And more often or not, there isn’t.

One big issue people also need to recognise is that understanding the behaviours of the application can influence the stories and requirements that we eventually produce. We need to know to a pretty good level of detail how our requirements fit in the global game. You can’t just impose them and pay no attention to what already exists.

Perhaps you could call this “Behaviour Driven Development”….?

« »