I was sitting in MartinFowler's XP talk at the Gold Coast earlier this week, and I was thinking about what a methodology really is. For example, I know that I like AgileMethodologies, but I can't see the particular benefits of ExtremeProgramming. I know that our project (MineStar) has some methodology, but not a heavy expensive methodology invented by a professional methodologist. So what is it that we've got? And why do I call it a methodology?

What we've got is some developers who take a pride in their jobs and follow some conventions, which enables other developers to do a better job. Because there is an ethical/professional motivation to follow these conventions, I will call them responsibilities.

The particular responsibilities that I can observe are:
	* make your code easy for other people to read
	* don't break the build
	* follow some coding and naming conventions
	* use the infrastructure wherever possible
	* ask for the infrastructure to be fixed, rather than working around it
	* don't deceive people about how well your code works.

Responsibilities I wish all of us observed, but don't happen, include:
	* write automated unit tests
	* document your designs.

ExtremeProgramming seems to suggest other responsibilities such as:
	* write your unit tests before you write your code
	* work in pairs in order to spread knowledge about the code
	* increase functionality in small increments and check in frequently.

My suggestion is that for a team to work effectively, it needs to choose responsibilities which lead to a working product, and which the team is happy to follow.

Many practices (responsibilities?) or methodologies are ignored for either or both of those reasons.
Of course, under no circumstance should the responsibilities be so light as to not be able to produce a working product, and if your idea of working is more strict (e.g. medical equipment control), then the responsibilities need to be more strict, and you may need to carefully choose a team which is more willing to accept more responsibility.

I'd like to hear what developers and methodologists think of this perspective.

-- JohnFarrell

''Another thing methodologies do is communicate what comes next.  I have found that very important when dealing with non-technical clients and newcomers to a project -- MarkAddleman''

----

John,

Whilst I agree with your comments, it's a little restrictive. MethodologiesAssignResponsibilities to everyone, not just developers. For example, XP has the Customer role, with very defined responsibilities. RUP has about a zillion roles, all with very well defined responsibilities.

One aspect that Martin emphasized in his talk was that, in agile methodologies, responsibilities are accepted, not assigned. The team should sit down and determine exactly what responsibilities everybody will work with. Some constraints can be handed down (for example, "don't break the build", and "write tests"), but if the responsibilities aren't accepted and agreed to, then they won't be fulfilled properly.

Responsibilities imposed by force don't work; people tend to rebel against them, which means that you have to discipline them, ultimately leading to kicking them off. Getting "buy-in", to use a clichéd term, is very important here.

The flip-side, of course, is that once a responsibility is assumed, the person must have the authority to fulfill the responsibility. -- RobertWatkins