Agility without anxiety

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.

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.

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……