Agility without anxiety
Does deliver early, deliver often equal deliver badly?
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".
Not everyone thinks it equals "deliver badly": Perforce doesn't, nor do its clients - small names like Salesforce.com or Nvidia. Or the company that literally, actually graphically, elevated team development to an art form: Pixar. That's why we have Perforce's Mark Warren in the studio to discuss how to do agile development properly: why it is needed, the right way to go about agile development, and how to avoid the mistakes that hobble it.
He's joined by Dale Vile from Freeform Dynamics who is here to tell you what you already told him when he researched it. Hey! Don't blame Dale, he's an analyst, it's what they do. His slides are world class. Tim Phillips will be pretending to keep control, and putting your questions to Mark and Dale.
Join us on September 18th at 11:00 BST. It's live. Have your say. During the Regcast you can use our Comment-O-Matic interactive portal to ask questions, agree, disagree, and tell us how agile worked for you. You might even use it to ask: "What, exactly, is a Comment-O-Matic interactive portal?"
Register for the free broadcast here.
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.
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.
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.