A Decade of Agile Programming — Has It Delivered? 395
snydeq writes "InfoWorld offers a look back at the first decade of agile programming. Forged in February 2001 when a group of developers convened in Utah to find an alternative to documentation-driven, 'heavyweight' software development practices, The Manifesto for Agile Software Development sought to promote processes that accommodate changing requirements, collaboration with customers, and delivery of software in short iterations. Fast-forward a decade, and agile software development is becoming increasingly commonplace, with software firms adopting agile offshoots such as Scrum, Extreme Programming, and Kanban — a trend some see benefiting software development overall."
Re:Maybe they did it wrong... (Score:5, Informative)
Well, yes and no.
There have been some developments since Brooks wrote No Silver Bullet that have helped by attacking the accidental complexity of software development - widespread use of garbage collection, for instance. But Brooks is still absolutely correct that the complexities of software have a lot more to do with the complexities of the human mental modeling, heuristics, and decisions that software replaces than they do with the challenge of converting that to something the computer can understand.
Works for us (Score:3, Informative)
I work in customer support for Agile Web Solutions [agile.ws], the makers of 1Password (a password management system) for Mac, Windows, iOS and Android. Agile development seems to work well for us.
I think that there are two reasons why this has worked well for us while not for others.
There are drawbacks, of course. What we like to think of as "surprising and delighting" and delighting our customers usually works, but sometimes we have to take steps back from something visible which we've tried. I think that over all this still is a "win" for us and our customers, but it can sometimes be disappointing.
A perceived (but imaginary) drawback is "wasted effort". We put a great deal of effort into getting data syncing among machines and devices to work via webDAV (and in particular, MobileMe). For a variety of reasons we had to abandon that approach and go with Dropbox (with which we are very very happy). To some this might seem like wasted effort, switching to a different approach after a great deal of effort has gone into the first one. But in fact, agile principles in this case simply mean that we don't fall victim to the sunk cost bias [wikipedia.org].
Re:Agile, scrum , extreme etc , its for managers.. (Score:2, Informative)
I think that you spent your time in a wrong kind of stand-ups.
You see, if you have up to 10 people on your team, and each one gives precise answers to those three scrum questions, you are gonna spend no more than 15 minutes in that meeting. After that, you know what all other people are busy with, so should any issue pop up, you know who to ask. This is less time to spend than if each one were asking another one by one.
Scrum done wrong: 1) a half an hour stand up; 2) scrum done in teams with more than 10 people; 3) off-topic discussions during the stand ups.
If you are saying you can fix half a dozen bugs in 15 minutes, then what the heck were you doing yesterday? Pushing trivial to fix bugs so that you can overclock your bugfixing karma the next day? Doesn't look like competent, anyway.
Re:Maybe they did it wrong... (Score:5, Informative)
No true Scotsman fallacy:
http://en.wikipedia.org/wiki/No_true_Scotsman
Re:Maybe they did it wrong... (Score:1, Informative)
Kind sir, the person who Truly Gets It is what's needed in *every* project. Agile is not special in this regard. Furthermore, this Totally Getting It person is required, also, to be in a position of some kind of executive control and influence. Too often we find that the local Person In Possession Of It is one who can do more than observe as bulk heads on the fail boat surrender themselves to the crippling dark waters of a combination of the three aforementioned categories of idiot.
From your anecdote, nothing about Agile is validated any more than any other methodology: what is breathtakingly obvious, however, was that your managerial overlords were prepared to let well informed technical people make some important technical decisions.
This is the best weapon we have against project failure .