+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.
would agile help as compared to not having agile then ? If yes, then what is the simplest methodology (books? blog post?) that is effective ?
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.
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.
I'm just guessing that this was not a team led initiative. It really must be to be successful.
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.