"Personally, if I was looking for a job and scrum/agile was mentioned in an ad, it would be enough for me to not even consider the posting."

+1.

And I say this as someone who worked for a few years on very successful agile projects (at ThoughtWorks).

(As always) It turns out that the best teams at ThoughtWorks had really good people, who would have made good software even if left to their own instinctive "methodologies".

For TW, "agile" is a kind of marketing differentiator, but many agile projects did (and do) go down in flames there no matter what marketing says.

It doesn't help that the biggest proponents and gurus of such methodologies are mediocre developers, as illustrated by the Sudoku by TDD effort and the Prime Number "kata" and so on..

Fwiw what has survived from my agile days is the practice of writing lots of tests (but no TDD, touch wood), especially when using dynamic typed languages, and a build per check-in running all the tests (loosely, Continuous Integration).

(Imo)The rest of the practices add little value when working with small teams of smart people attacking interesting problems (vs large teams of mediocre developers working on bloated enterprise software).

In my opinion, Scrum is the most "scammy" of all the "Agile methodologies" [1] but the last time I mentioned this here someone making a living as a Scrum Master(TM) wrote me a series of angry mails on how his notion of importing wisdom at some of his clients was being resisted by some "code focused" developers "just like you" there so I'll say no more on that.

So my takeaway wrt mentioning agile,scrum etc in job posts = if you want to hire/ work with large teams of mediocre developers on "standard" projects, by all means insist on the specific process du jour in your job posting.

If you have/want to build a team of sharp developers, product managers etc, let them work out their own "methodology" without imposing practices, checklists, coaches etc on them. It just turns away good candidates.

I understand that people can get quite religious about their favorite methodologies so I'll conclude with

"Just my experience and opinion. YMMV."

[1] "Lean Software" is a close second.

The question is this - suppose you had to work with not-so-great developers or, more realistically, young freshers to software development ?

would agile help as compared to not having agile then ? If yes, then what is the simplest methodology (books? blog post?) that is effective ?

I agree with this. I was lead designer in a team developing a multi-format game about 3 years ago. We switched to using agile and it really hit relationships and the way we worked in the team.

Rather than the lead programmer, artist, designer, and producer having a good picture of the development process, the project manager was the only one who had a view on where we were in the project. He was not from the games industry which made it even more difficult.

We were only using a subset of agile, but it seemed to break up the team rather than get them working together.

I'm not saying this is the fault of the agile method, or that agile is wrong for games development, but in my experience it was enough never to want to use it again.

What did you switch from? Which agile method did you use?

We switched from a system that had just worked organically over several previous projects. Weekly meetings among the leads with the producer and project manager. Each lead would work out the tasks, time limits, and take into consideration other departments deliverables. Inter-departmental communication was also handled by the leads, there was no pairing off, or groups of different disciplines working together, although this did happen when necessary throughout a project.

As for what Agile method we used, I have no idea what specifically the method was called. We were told our team was going to experiment with Agile but keep it very simple. Teams of 2 or 3 were formed for specific tasks from different departments. Weekly time slots allocated, and reviews done at the beginning of the following week.

"We were only using a subset of agile, but it seemed to break up the team rather than get them working together."

I'm just guessing that this was not a team led initiative. It really must be to be successful.

And why is that?

So you prefer waterfall ? Most of my gigs have been in big corporate environments where people are considered "resources" and agile has nothing but savior for me . Bad agile is always better than even good waterfall .

Ermm, one of the tenets of Agile is that all members of the team are interchangeable (i.e. anyone can take anything from the backlog).

"Individuals and interactions over processes and tools" ...people are more important than any process ..and considering them "resources" is not valuing people enough. What i said has nothing to do with team roles

You'll find once you start referring to PMs as "Powerpoint resources" they stop :-)

But they are not to be taken away from the team during a sprint! There is absolutely no recommendation to change the teams between sprints for the sake of changing either.

The interchangeable part (although I have never heard it called that) is more that knowledge should be spread, so you don't end up with domain experts that end up "owning" part of the code.

What do you base that opinion on? I'm certainly not a fan of huge amounts of process, but I think I'd be more frightened of going to work for a company that had no process at all.

What kind of process would you prefer to have in your company?