What does "Agile Development" mean to you?
Feb. 5th, 2014 01:33 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jducoeur[Not strictly aimed at programmers, this time -- I'm interested in hearing from anyone in the software field who has an opinion.]
I was in an interesting discussion on one of the Scala mailing lists last week, and we wound up off on a tangent about "Agile". My correspondent described how he strongly dislikes Agile, and why -- and the interesting thing to me was that his definition of Agile not only didn't match mine, it was in some ways directly *contradictory* to mine.
I've been starting to realize that, 15 years into the process-management revolution in software, the term "Agile" has become ever-squishier. This hasn't been helped by management consultants who sometimes spout complete nonsense, or more often take a specific dialect of the idea and say "This is what Agile means".
So here's a quick question, aimed at my many techie friends: what does the word "Agile", in the context of software development, connote to you? What are the two or three *most important* aspects of it? I'm not looking for answer just from the experts here -- I'm at least as interested in the viewpoints from the people who have only been reading about it in the trade press or blogs, and what impressions you have gotten. And I'm curious whether the viewpoints and priorities differ between, eg, the programmers and the project managers.
(I have strong opinions about this myself, of course -- I've been an active proponent of some of these ideas from almost the beginning. But I'd rather hear your viewpoints first, before I spout off...)
I was in an interesting discussion on one of the Scala mailing lists last week, and we wound up off on a tangent about "Agile". My correspondent described how he strongly dislikes Agile, and why -- and the interesting thing to me was that his definition of Agile not only didn't match mine, it was in some ways directly *contradictory* to mine.
I've been starting to realize that, 15 years into the process-management revolution in software, the term "Agile" has become ever-squishier. This hasn't been helped by management consultants who sometimes spout complete nonsense, or more often take a specific dialect of the idea and say "This is what Agile means".
So here's a quick question, aimed at my many techie friends: what does the word "Agile", in the context of software development, connote to you? What are the two or three *most important* aspects of it? I'm not looking for answer just from the experts here -- I'm at least as interested in the viewpoints from the people who have only been reading about it in the trade press or blogs, and what impressions you have gotten. And I'm curious whether the viewpoints and priorities differ between, eg, the programmers and the project managers.
(I have strong opinions about this myself, of course -- I've been an active proponent of some of these ideas from almost the beginning. But I'd rather hear your viewpoints first, before I spout off...)
(no subject)
Date: 2014-02-06 02:43 am (UTC)The change may be "change to the requirements", "change in the architecture", "change in who we're building this for", or maybe even "change in who's on the team", depending on what you care about.
"Gracefully / without breaking" is imprecise, but I can't think of a better phrase offhand. It refers not just to code, but to architecture, organization/process, and perhaps people. (Handling sudden / frequent change by burning out your coders is bad.)
"Gracefully / without breaking" does *not* mean "without cost"; you can never get the cost of change to zero. Minimizing cost-of-change / risk-of-change tends to be a strong objective - though that, itself, comes with costs.
Most everything else I associate with Agile are various means towards this end, which may work well or poorly depending on what other habits you pair them with, the environment in which they're used, etc.
I've never worked in a place which claimed to use Agile development. There was discussion of it at my last job, but while we borrowed a few notions from various Agile methodologies (eg: More Unit Tests, more frequent but shorter status meetings that my boss called Scrums), we never really went whole-hog. I think we'd have had real trouble with it, based on past difficulties getting time from stakeholders to even briefly look at what was being built for them, and upper management's desire to run Engineering at 100% utilization all the time (meaning no spare capacity for high-priority requests, leading to huge amounts of context-switching and large back-burnered task stacks).