The reality is that I can tell whether the person I’m interviewing really gets it. If you approach it with the attitude that it’s buzzword nonsense, then I’m going to spot that. And I’m not going to hire you.
Basically, you’re advocating being a hypocrite in a job interview. This is a bad idea.
Firstly, since about 2001, Agile should be generally considered the de facto way to develop software, in most business cases.
You seem to be stuck on “design”, but these things do not just apply to design.
Agile is not a process, it is a collection of paradigms and methodologies that enable better code, and better ways of managing the job of developing software.
Agile really starts at the developer/code level, but also covers philosophies and methodologies that enable the development of process(es) within inidividual companies which cater to their particular situation(s).
Scrum is a different story.
Scrum is a process, and has nothing to do with Agile, unless you choose to use the Scrum process along with Agile coding and development paradigms.
That says alot, and more people should admit to that.
Instead, they give themselves titles like “Engineer”, which is purely smoke-and-mirrors…
Well, it isn’t really, since Scrum and Agile have been around for a long time.
However, they’ve been around long enough, and are useful enough (if one knows how to use them effectively… which most people/business don’t seem to), that they have become buzzwords for management and people that only have a vague idea of what they actually are.
Many businesses are jumping on the bandwagon, because managers think that implementing these things (or what they think they are) will be a magic pill, which it won’t.
The whole thing is a sticky wicket these days, since managers want it implemented, and expect magical results, based on their own ignorance.
Again, you’re a coder.
It’s great that you admit that, as many, many others who should, don’t.
The easy way out is to start with “what is Scrum”?
While studying up on that, you’ll get some info about Agile paradigms, but just as it applies to the development process. But, that’s usually all that managers may be somewhat familiar with anyway.
My suggestion is to get Bob Martin’s book “Agile Software Development: Principles, Patterns, and Practices”.
He has a great understanding of Agile Development, and this book is the best source I’ve come across.
All managers attempting to do Agile Development should be intimately familiar with his book… but they aren’t.
Also, there is a ton of information on Agile Development on MSDN.
A guy that has blogged about Agile philosophies and paradigms is J.D. Meier.
Check out this brief post that is more philosophical, and then connect to his other posts and other blogs.
It should definitely get across the point that Agile is more philosophy than process, and you should learn alot along the way.
Get familiar with it, not because people want you to, but because it is the best way to approach developing software.
Little bit of a zombie here, but I found an essay in which the author argues that there are good reasons to think that we can learn to do better estimates in an agile model than we can with a large project based on recent developments in psychology.
Hm. The message that I take from the blog post (from a decidedly non-Agile standpoint) is “you can’t estimate any work more than one week in advance, so don’t even try.”
Which is probably fairly accurate, but not particularly helpful from a business standpoint.