This is a thought that I have been struggling with for a while: Are agile methods working better for managers and developers "born agile", i.e. that was never exposed to more ‘waterfallish’ structured approaches, or is the real power of agile only reaped when you have exactly that background?
Last week my interest in the issue was resparked. I had a discussion about Scrum with the students in the e-business class that I lecture. It was really inspiring to see the eager contributions (not always the case, I must admit...) and the students' experience and opinions about Scrum. Nevertheless, I also felt that compared to when discussing agile principles with my colleagues (not all grumpy and old, but you get the idea...), we were missing some common ground and viewpoints that are useful having as a background when consciously deciding to work in an agile fashion on a project. Thus I wonder if those never exposed to such documentation-heavy methods miss out on something, even if we all agree agile methods are "better"?
I find it a bit hard to pinpoint and be specific about the relatively vague feeling/postulate. I’ll try with two, maybe relatively random, examples: If you have grown up with carefully designing an architecture before starting to code, you’ll know which parts to include in the “vertical part" of a broad prototype/first-sprint-end-version[1]. Or, if you have experienced the often large gaps in understanding of a formal specification, you can use that knowledge to document just the right stuff in your user stories - knowing when to formalize to clarify. That kind of knowledge, in my opinion, goes beyond just being "experience" - it is also tied to the more documentation-heavy approaches and how to work with the shortcomings of those.
It is also my opinion that, at this point in time, the vendor side of most projects is often more keen on working with agile methods than the customer side. In that regard I also think the grumpy old fellows have an easier time, knowing how to smooth things a bit out by providing the linkage between structured reporting and the measurement of progress in terms of pure increments of working code.
My preliminary conclusion is that currently it is certainly no disadvantage to have been exposed to more classical project management and software development methods before moving to agile. Rather the contrary. But, I also have a positive outlook towards more and more buyers of software projects specifically wanting to work using agile methods. When that happens I might end up just grumpy with no advantages of it at all. Well, I guess I can resort to thinking about how much better things were in "the good old days"[2] (well, not really - but "If you take away make-believe from the average man, you take away his happiness as well").
[1] - It is my strong opinion that the first deliverable should as broad as possible in terms of functionality, but as indicated in the above paragraph I think it also makes sense to select some narrow (and often tricky) parts of the solution for a full vertical proof-of-concept as early as possible. Selecting these is often more an art than a science, and my little fear is that this skill is not as well nurtured for the "born agile" colleagues that are currently graduating.
But I might be wrong and just "not getting it", because of my somewhat old-fashioned mindset... I also wonder if it is wise or misled to use sprint N for "architecture of X" or "design of X" and sprint N+1 for "implementing X"- isn't this just waterfall in disguise? That was a sidetrack (in a footnote!); maybe a post on that later.
[2] - Of course, being born in the late seventies, I don't know the really good old days, when everything actually was better. Or so I've heard.
