Some Reg readers think so. This is what a few of you tell us about agile development: "Often of a lower standard and the system will inevitably be less reliable". "If you don't have good people, you're screwed". "It leads to several wheels being reinvented in disparate ways". Ouch. Not everyone thinks it equals "deliver badly …
Agile development works well
if done properly it can make life extremely easy. It segues over one of the major problems in software development - the client being shocked by what their data says about them when its finally organised and functional and the MBA trying to say its all wrong.
Re: Agile development works well ... if done properly
Why is it that whenever the topic of "Agile development" comes up, someone feels compelled to state that it needs to be done properly ?
The answer, I guess, must be that doing it properly is a) hard and b) anything but obvious ?
Or maybe it's that it's much easier to specify "Agile is not ..." than "Agile is ..." ?
Re: Agile development works well ... if done properly
- why the need to say it needs done properly?
It's probably the same thing that drives 'lower-end' car repair shops coming up with names that contain 'excellent' and 'expert' .
On a totally unrelated note - drove by a car repair shop somewhere in the boonies. "Excellent Car Repairs - puts the Irv in Service".
Got me thinking - kinda like Dogma with the Catholic Church's ad campaign. Might have included 'Catholic Church - Puts the Awe in Gawd'.
But, coming back to Agile. Some parts can be done Agile-y - but let's make an effort of designing / building some sort of foundation first, using more traditional approaches? Then at least you know that you're not constantly rewriting / redesiging the most basic of functionalities.
To me Agile is perfect for a project that has loads of budget, and most of the stakeholders don't really know what they want to do with that money.
(one party in the stakeholders does, of course. the people providing the manpower for spending that money).
The problem with agile
The problem with agile is that it is most of the time used as a methodology smoke-screen for having no methodology. It works fine if you have a complete specification first and a have a design for the system worked out first. Then you can deliver frequent iterations to make sure that what is in the specification and what has been designed is actually what the customer wants (it frequently isn't).
The notion that you can use "agile" development methodology to avoid a thorough requirements analysis, detailed specification gathering, and working out a reasonably detailed design is laughable.
Agile is just a euphamism
For shipping alpha and beta quality code and letting the user test it. But hey, if its got its own buzzword is sounds so much more professional.
Perceptions clearly wrong
a) Agile is not a no-methodology system. It is highly methodical with a strong requirement for many things which are there to ensure efficient working.
b) It has a requirement for a person to own and maintain a requirements list (specification), while this is open to change just as the world is, but it has to exist and if the person in charge of this is no use then you are in no worse a position than with a useless specification in a standard waterfall process.
c) It doesn't require a design for the system to be created first BUT it doesn't say you shouldn't do some design. The amount required is going to depend on the competence of the engineers. I have seen many designs for products followed through and the product dropped at the very last moment after a lot of work because the product is no longer competitive or relevant to the market. Under a well managed agile project a decision would have been taken to change the specification, this may have led to a redesign - or even possibly to the scrapping of the project long before the 'end date' and the realisation the team had spent months or years on something worthless.
d) As with ANY project someone needs to create the requirements (in 'scrum terms' the user stories), that these might change does not negate the requirement to create them in the first place. One thing that many people (including the fans of agile) fail to note is that a company needs to look at the project - its aims, the requirements it will create, the cost and timescale of doing this versus the benefits BEFORE the project enters the (usually more) expensive development phase. With agile the person in charge of the requirements can change them (just as change requests can change a waterfall project), the company needs to ensure that the requirements owner is kept within a reasonable cost and within the bounds of what is the over all aim. This is exactly the same as required with any other project methodology. Agile does NOT get rid of this basic requirement.
e) And as for shipping crap code for users to test there is no more chance of that than you get with waterfall methodologies. The team tests as it develops and the internal releases are of at least as good a quality as any alpha or beta release from waterfall. The decision to release the developed product is made by the guy who owns the product - as it is with a waterfall project. What many fail to realise is that with agile there is nothing against running a period of test and fix at the end as you do with waterfall. In fact, just as it is with waterfall this period is needed.
f) The engineers are recruited to be intelligent enough to develop your product, so trust them to be able to work out the how, who and when of this.
There are of course numerous companies implementing agile in terrible ways and abusing the principles.
Deliverable rather than deliver
There are many issues with Agile. There is no "proper" way to do it. Proper way to do SCRUM etc yes, but these are just rigid methodologies bolted onto something that was never inteded to have such formality. Even then SCRUM and the like are fine if just used as a guide and forget the "thou must do X" rules.
The key problems I see though are
1) *All* stakeholders which often goes right to CEO level, must be signed up to it and understand it.
2) Stop trying to *release* every week, two weeks.
The latter doesn't mean you stop doing your sprints or whatever you like to call them and you should still have a tested build that you *could* release if necessary. It's just that rolling it out every couple of weeks when it's a buildable and tested product but incomplete, clearly a 'beta' to the user, and may be time consuming to release, and fills your backlog with more issues each time is not ideal. You just end up spending half the 'sprint' planning for the next one.
Just be in a position where you *could* release if you need to, but rather wait until you have the finished polished goods. Ideally don't let the user and more importantly the CEO see the product until you're happy. Else they'll want to make changes! ;)
I've seen Agile done fairly well, I've seen it done badly, but I prefer some attempt at it rather than the opposite to Agile, the "bugs and feature requests keep rolling in, and we keep developing endlessly and never releasing, never having time to test properly, and then suddenly rush a release when the boss demands it that's an utter mess" approach.
Agile = Meh
OK - I'll Bite,
My overall experience of Agile has been extremely underwhelming.
The crazy bit is that it started as a pretty good idea (Kent Beck etc) but the 2 best features (IMO) Test Driven Development & Pair Programming are the one's that are never implemented.
"We haven't got the resources for PP"
"We haven't time to invest up front in a TDD Framework"
Instead you get the bits that Mgmt like because it gives a massive rod to beat the Devs with.
Typically you're given 5 mins at the sprint meeting to work out how long something will take - then when you finally figure out that you've underestimated - you get shafted. So the Devs cop on & start to game the Sprint - massively over-inflating the easy tasks so that they fill their capacity.
Agile is great for little noddy tasks that you'd give the college work experience guy.
"Add a widget to this screen", "Write a report to show X"
For any significant Software Delivery it falls over.
Also I hate the way "Agile" always puts up this 20yo strawman parody of Waterfall methodologies - like we're all still writing COBOL on green screens.
Ask yourself - would you use Agile to: Move data centres? Implement SOX? Port your Software to iOS or Faceback apps? Good luck with that.
Does deliver early, deliver often equal deliver badly?
It does if you are an obstetrician.
Agile treats the symptom it a cure that is needed
There have been many articles that puts "agile" into perspective to counter the zealots who have over hyped this “IT” initiative – so what’s new! The fact is for business there is no need to code which is expensive to build and to change. Listen to leading analyst Naomi Bloom http://bit.ly/ckeutZ There is now the new alternative “definitional object model driven development”. Naomi is standing up and making some brave and hard hitting statements in particular this http://infullbloom.us/?p=3222 the “object model driven” future for enterprise software creating a “moat” for vendors to cross.
“Writing less code to achieve great business applications was my focus in that 1984 article, and it remains so today. Being able to do this is critical if we’re going to realize the full potential of information technology”
“….how those models can become applications without any code being written or even generated”.
“If I’m right, you’ll want to be on the agile, models-driven, definitional development side of the moat thus created…..”
In a subsequent tweet author said “It really matters how your vendors build their software, not just what they build” and Michael Krigsman a leading analyst tweeted referring to the article “Pointing to the technical foundation of future”.
This is highly disruptive but it works and has been proven but there are those that like to keep the old ways……