First, you don’t have to convince me to use agile techniques. At least some of them are used in my teams for a couple of years already.

Talking about what you should do and what you have to do to call yourself agile, well, it wasn’t me who started this whole orthodox thing.

You’ll often find opinions that refactoring is not optional – you have to refactor if you want to be agile. Same with unit test – they’re obligatory. Or this one about Scrum which rarely uses a word “should,” let alone “you’re adviced to.”

I agree with your approach to take these techniques which suit your team fine and leave those which don’t work. That’s exactly how I treat every methodology around.

But it’s not me who try to put labels “agile” or “non-agile” on everything and everyone. I don’t pretend our team is agile just because we use burndown charts, share office space or have a cross-functional team. Actually I don’t care how agile my team is as far as we’re doing good job.

However if we come up to definition of agile methodologies as complete wholes I still say they’re formal. If you choose just a few techniques from here and there you’re most likely much less formal, but don’t ask me whether you’re still agile or not. There are zealots out there who cares, but I’m not the one.

As you said “agile is quite strict in terms of rules you should follow” – I’d like to make a point of word SHOULD :) In my opinion, should means “you are advised to” but you do not have to.

In general, whenever we follow strict rules we’re more formal. It doesn’t have to be about generating a lot of document. It can be, and it is when it comes to agile, about actions we perform.

“Meet often and keep your meetings short” is pretty informal. “Meet everyday for 15 minutes and allow no one to sit down” is more formal. “Develop high-quality code using techniques which you believe work” is informal. “Write tests first, don’t develop code which doesn’t break any unit test, program in pairs, switch sits in pairs at least every half an hour, refactor at the end of implementation of each user story and have Kent Beck poster pinned over your desk” is way more formal. Just two examples from the top of my head.

Don’t get me wrong – I don’t say these techniques are wrong. I just say that agile is quite strict in terms of rules you should follow.

I was never trying to prove that agile is stiff. Of course it can be, and should be, adjusted every now and then but this doesn’t change the main point.

By the way I think there’s no methodology which forbids you to adjust the process in any way so agile definitely isn’t unique here.

Pawel, could you clarify what you mean by “formal” keyword? Does usage of some good/well-working techniques mean for you formal?

For me Agile is above all: feedback from customer, team; collaboration between people in order to achieve common goal; shipping often; continuous improvement of your process. Especially the last one – continuous improvement – gives you possibility of changing your process rather than following something that does not work. The team is fully entitled to apply new and resign old techniques – you don’t have to do your work every time in the same way.

I consider XP as very strict methodology when talking about following rules. Actually I haven’t worked professionally in the team which used XP conservatively.

On the other hand I’ve seen several practices taken from XP and implemented in other environment and it worked pretty darn well. I didn’t call it XP though. That’s by the way approach which is closer for me. Take parts which suits you the best and use them instead of following everything by the book.

I think each process is pretty similar when it comes to tolerate people’s failures. The difference is in techniques used to deal with it. With XP you try to prevent failure as you work. In old-school methods you do it in more reactive way.

I’m curious why do you think you need a dictator as PM with XP?

Simplifying things much (too much) agile came with rejecting old-school methodologies. With no alternative at hand most of the time it would end in chaos.

Of course the goal is the main value here. If you can reach it and do it fast and get good quality with chaos all around you, well, that’s great. I won’t advise you to change your behavior.

However in vast majority of cases putting a clear goal for the team is not enough to achieve success. You need to give people some guidance or every of them will try the way he thinks is the best. It isn’t the perfect way of teamwork, is it?

Of course there are teams out there which do pretty good job in self-organization but they use the same techniques you’d choose if you were in charge. The difference is the decision is made by the team not by the manager who force her own idea.

Even if the team makes the decision and it ends up with agile approach it’s still formal. Which was my point.

You’d better have a dictator as project manager when you’re doing agile! Have you tried doing XP and skipping one of the practices? The entire systems breaks! Conversely, heavier processes are more tolerant to ‘human failures’ such as missing unit tests for something, or programming without a partner.

Which comes first the goal or the organisation around it?

In my experience if you have a clear goal which the team is committed to, pretty much anything works (and the less non-essential process you put in the way of performance the better).

If you don’t have a clear goal or the team are not all committed to it then that’s where to start. Motivated teams are more than capable of self-organising.